ryan

This thread might have some more useful stuff too: http://processwire.com/talk/index.php/topic,37.0.html I didn't realize there was a need for more, but I can definitely add more. I can see the value with what you are mentioning here. Another possible way to handle a /en/ or /fr/ at the beginning would be to install ProcessWire in a directory named /en/. Then create a symlink on your file system called /fr/ that points to /en/. Your template code could examine the URL it's being loaded at to determine which version of content to show: <?php if(strpos($_SERVER['REQUEST_URI'], '/fr/') === 0) { echo $page->body_fr; } else { echo $page->body_en; } I haven't actually tried it, but I think it would work.

Thanks, I will definitely need help testing. Also wanted to mention that you can always take the approach mentioned here: http://processwire.com/talk/index.php/topic,54.msg917.html#msg917 This essentially duplicates what you could do with the new user system (in the areas you are describing), though it just takes more work on your part. Also see this thread too, for another approach: http://processwire.com/talk/index.php/topic,17.0.html Thanks, Ryan

Thanks for taking the time to write this up. I think what you are describing is very similar to what I'd like tagscript to progress to in terms of capability, so I appreciate having this written in more detail. My thought is that you will be able to define a new {tag} either with a function (like in that module above), with a separate module, or by pasting the tagscript snippet into an admin field (which doesn't yet exist, but will be built as a module). If you have the tagscript module installed, it will always translate tagscripts in you templates when you enable it. You'll also be able to selectively turn it on for any custom fields (like if you wanted to enter tags in your bodycopy or something). Being able to turn it on in custom fields is one area where I think tags bring something very useful to the table... you wouldn't ever want to enable PHP in a field, whereas I'd have a much higher comfort level (security wise) with enabling tags in a field. In terms of syntax, let me know what you think of this? Tagscripts can be simple like: {tag} Tags can have arguments, like: {tag, name="value", name="value"} Or tags that translate directly to an API function, and be "open", allowing you to create the markup (the closed version would generate it's own markup): {pages.find parent=/news/, featured=1} <li><a href="{url}">{title}</a> {date}</li> {/pages.find} That would be the equivalent of: <?php foreach($pages->find("parent=/news/, featured=1") as $item) { echo "<li><a href='{$page->url}'>{$page->title}</a> {$page->date}</li>"; } I like the open-tag approach, where you can define your own markup. I'm less comfortable with tags that output markup on their own (level 2 templates, as you described them), but also recognize that not everyone wants to recode the markup for everything, all the time. That's why the pagination and comments modules generate markup... because I don't want to have to code that markup for every site. So that's an admission of value for tags that output markup, but I think you always have to be careful with anything that's generating markup you didn't write. So my though is that for any given tag, you can write a closed version like {tag} that generates it's own output, or you can write an open version (like in the example above) or {tag} ... {/tag} where it uses what's in between for output, allowing you to substitute additional tags to obtain the raw values of fields within the {tag} ... {/tag}. I believe this is similar to the approach that Expression Engine tags with it's tags. When working on a site that involves a team of people responsible for design/development, you are absolutely right about this. For most of the sites I work on lately, it's just me building it and then maintaining it over time. But that's a unique situation, and not how it works half of the time in other work environments. I would agree that tags would be preferable with the site you are describing. While I personally find native PHP solutions simpler and easier to maintain for my own use, I would be inclined to use tags in situations where I knew other designers/developers were going to be making edits too. I plan to keep ProcessWire's core always PHP API based, but am very enthusiastic about building/collaborating on a module that can make the API fully accessible to tags, and let users define their own tags/snippets in a format that is easy to do and easy to share among sites. I think this will broaden ProcessWire's appeal with one of it's main target audiences (designers), though you said it better than me. Thanks, Ryan

Rebecca, thanks for your feedback. I think what you are saying makes sense. ProcessWire is a new project and ideas are valuable and important. As far as voting goes, maybe we need something more official, but when a lot of people join in and say they want something, that goes a long way (I guess this is like voting).

ProcessWire won't ever stretch or squeeze an image, so no matter what dimensions you give it, you can count on it to maintain the proportion of the actual photo subject while still maintaining the dimensions you've given it. If you need to deal with a gallery of photos, all with different dimensions, then your best bet will be to feed $image->size($w, $h) your target dimensions, and most likely the result will be a good one. If you need a fixed width AND height for your automated thumbnails, I've found that cropping/sizing to the center is the only way to deal with unknown dimensions ahead of time. And that's why ProcessWire does this. The only exception I could think of is if you are dealing with photos that always have the subject weighted to some corner, though I've not had to deal with that situation before. Of course, if you only need to maintain one dimension (whether just width, or just height) then all of this is a non issue. But give it a try, I think there is a strong possibility that you'll like the result.

Well the API to the users system probably won't change much, if at all. As you've seen, it's already nearly identical to the $page interface. So when you upgrade, I think best case is that it'll still work, but you'll have some unnecessary code. Worst case is that you'll need to convert your new pages in /tools/users/ over to the new users system (which you may want to do either way). But it won't be hard, and I think we'll be able to get you through the conversion with just a few API snippets.

The new user system will provide better support for developing your own user registration functions. But it's probably still a month or so before I'll have that ready. In the new user system, users are actually pages, so you can interact with them, add fields to them, and so on, in the same way.

You are doing it correctly, but it looks like I gave you bad advice. It did support undefined fields within a user at one time in the past, but looks like it's no longer the case (I just spent some time in the code to confirm). I apologize for accidentally telling you something incorrect before. The whole users system is being converted to pages as the next item on my to-do list, so the users system is fairly barebones at present, as you can tell, and I've left some things out of it as a result. What I would suggest is that you start using pages to store your user information now. Setup a new page to serve as the parent for users, like /tools/users/, and remove the guest role from that page so that it's not publicly accessible. Create fields for email, order_id, ipaddress, amount, signupdate and add them to a new template you create (user.php or something like that). Then change your code: $u = new User(); $u->name = $username; $u->pass = $password; $u->addRole($role); $p = new Page(); $p->parent = $pages->get("/tools/users/"); // you define where you want them $p->template = $templates->get("user"); $p->name = $username; $p->email = $email; $p->order_id = $order_id; $p->ipaddress = $ipaddress; $p->amount = $amount; $p->signupdate = $signupdate; $u->save(); $p->save(); Then when you retrieve a user, retrieve it's corresponding page for your info: $u = $users->get("$username"); $p = $pages->get("/tools/users/$username"); Taking it further, you could also make a function that loads users and would automatically populate your page fields into the $user object. In this way you could interact with the $user object like in the example you posted. But you would just want to use these functions below to get and save users, rather than the built in ones: <?php function getUser($username) { $u = wire("users")->get($username); if(!$u) return false; $p = wire("pages")->get("/tools/users/$username"); foreach($p->fields as $field) { $u->set($field->name, $p->get($field->name)); } return $u; } function saveUser(User $user) { $p = wire("pages")->get("/tools/users/" . $user->name); if(!$p->id) $p = new Page(); $p->name = $user->name; foreach($p->fields as $field) { $p->set($field->name, $user->get($field->name)); } $u->save(); $p->save(); } Then you could access your fields in the same way as in your original example. These are just rough examples typed directly in the browser, so they haven't been tested and you would just want to use them as a starting point rather than as a complete solution.

If you ask for an image of 100x100, then it's always going to return an image exactly that size. For a 400x200 source, the result would be scaled to 200x100 then cropped to 100x100 (though I think it does it in one step). It always crops to the center. I will make it able to crop to corners if anyone ever needs it (I personally haven't needed it yet). You asked about a 100x50 image too. If you wanted it to return a thumb of your 400x200 image at 100x50, then you'd want to do this: $thumb = $image->size(100, 50); Or if you just wanted it sized to 100 pixels wide, and a proportional height: $thumb = $image->width(100); Or if you just wanted it sized to 50 pixels tall, and a proportional width: $thumb = $image->height(50); The above 3 snippets would produce the same result (100x50) for a 400x200 image.

Okay I think that's it then. 'data' is a field name used internally by ProcessWire. It should have given you an error about that, but it looks like I hadn't yet added this to the list of reserved words. I'm adding it to the list, so thanks for finding it! Ryan

Glad that you figured this out. Thanks for posting the solution.

I think you are right about the sessions dir. That could definitely account for the issue you are describing. You might want to edit /site/config.php and change "$config->debug = false;" to "$config->debug = true;" to confirm it. The only other possibility I can think of is if you have turned off the trailing slash in your admin template. The admin template requires the trailing slash. Technically it's possible to turn it off by editing the admin template, and that could cause this same issue you are experiencing. You can tell if this is a problem by looking at the URL when you are on the admin login page. If it is "/admin/" then no problem, but if it's "/admin" (no slash) then that could be a problem. However, I'm guessing it's more likely the sessions directory issue you mentioned.

Thanks Abu, that would be great. We're still a little ways off from having multi language capability in the admin, but it is one of the high priorities on the roadmap, so hopefully we can tackle this soon.

The title field will likely get locked down (required field name) in the near future, just because I think it'll make life a little more difficult for module developers if we don't... for example, without a known title field, there would be no way to identify what the actual title of a page is, just the URL name. As a result, I don't recommend changing the name of the title field.

Not yet, but the user system is actually being converted to a type of pages, so you'll have a lot of control over this, as well as the same level of flexibility that you have with pages. This is under construction, so not yet on the live source.

By any chance do you have a field named 'data' in your list of custom fields?

Thanks for this info. I am not near a computer today (other than this cellphone), but will find and fix this error tomorrow. It appears that the error is happening in the core rather than due to a specific API call, so I'm assuming this is a bug, and should be easy to fix once I get back to the office.

Can you provide more info or steps to reproduce? When did it start happening, and what events preceded it happening? Does it happen on All pages, or just one or some?

By default, tinymce is configured kind of conservatively. So it removes attributes that aren't specifically allowed in it's configuration. You can change this behavior when configuring the field, under the "tinymce configuration" portion. Let me know if you need help. It's a little cryptic in that section, as it's in tinymce's format.

You can also just call it /site/ if you prefer. We only use /site-default/ initially so that people can continue to keep it cloned easily via Github without worry of it overwriting anything in their /site/ dir. As a result, there is no /site/ dir on the GitHub source (instead it's /site-default/ solely for GitHub). This is correct. Also note that the installer moves /site/install/files/ to /site/assets/files/. So if you were creating a new profile, you would copy your /site/assets/files/ to /site/install/files/ before zipping up your /site/ dir into a new profile. Also correct. This is so that you can create a site, and then easily export it as a profile just by exporting the database. The installer requires a fairly simple SQL file since ProcessWire uses PHP's MySQL commands to create the DB and insert rows. so things like extended inserts and such probably won't work. So here is the command I use to create a dump for a new profile: mysqldump --complete-insert=TRUE --add-locks=FALSE --disable-keys=FALSE --extended-insert=FALSE --default-character-set=utf8 -u[user] -p[password] [db_name] > install.sql After that, I edit the dump file with a good utf8 compliant editor (I use BBEdit/Textwrangler), and remove any extra junk that MySQLdump adds at the top and bottom of the file. This means remove anything that is not a "CREATE TABLE" or "INSERT" statement, unless you specifically want it there. Then I find the part where the insert statements are for table "users" and I remove all users except guest (ID 1). Likewise, remove all the insert statements for table "users_roles" except for the first one, which assigns role "guest" to user "guest" (1,1,0). Then your install.sql is ready. You are correct on all of this. You basically just create the site you want the profile to be. However, you shouldn't need to manually delete any images from assets, as deleting them on the page (or deleting the pages you don't want) will handle deletion of them automatically. This is right, but you can exclude everything from assets other than the dir itself. Your /site/assets/files/ should be copied or moved to /site/install/files/ (as mentioned above) before creating your profile. Why do we do this? Well if you deliver the profile with /assets/files/ already in place, and the file permissions weren't retained for one reason or another (like when they FTPd them or something), then you'd have to tell the user how to make all of the files in /assets/files/ writable. If they don't have shell access, this could be a time consuming process... a lot harder then just making /site/assets/ writable. By making ProcessWire move them from /site/install/files/ to /site/assets/files/, it ensures that there can be no issue with messed up file permissions, since ProcessWire will have created the files. If for some reason, ProcessWire can't move them from /site/install/files/ (like if permissions were lost when the user uploaded the files), then ProcessWire will copy them instead. Either way, it'll be able to complete the install with minimum hassle to the user. For the time being, the install profile will include the entire database. But not having made a lot of different install profiles yet, I've not given a lot of thought to doing it differently. It is possible that the core tables will be created/installed separately in the future. If you want to make something future proof, perhaps I should go ahead and make that change now... moving the core table creation outside of the site profile. This won't be too difficult from this end, and I imagine I could have that chance in place within a week. If it helps, here is my profile creation shell script. It creates a profile from a site that is running, so it goes and moves things around temporarily, creates the zipped profile, then moves them back. You'll see several things that get renamed to a ".old" version. My zip command (and .gitignore file) excludes files ending with ".old", so they are basically removed from the picture temporarily. I run this script after I've already exported the database, and placed it in /site/install/install.sql, using the method mentioned above. #!/bin/bash cd /Users/ryan/htdocs/sky/ <-- sky is the root dir of my PW installation chmod -R og+rw ./site/assets/* rmdir ./site/assets/files/* <-- this removes blank directories mv ./site/assets/files/ ./site/install/files/ mv ./site/config.php ./site/config.php.old <-- take the live config.php file out of the picture temporarily mv ./site/config-original.php ./site/config.php <-- and use a config.php without DB settings in it mv ./site/assets/cache/ ./site/assets/cache.old/ mv ./site/assets/logs/ ./site/assets/logs.old/ mv ./site/assets/sessions/ ./site/assets/sessions.old/ mv ./site/assets/installed.php ./site/assets/installed.php.old zip -r -v ./site.zip ./site/* -x@zip_exclude.lst <-- create the zip file, excluding stuff mentioned in zip_exclude.lst mv ./site/install/files/ ./site/assets/files/ <-- now move everything back so our site will still work... mv ./site/config.php ./site/config-original.php mv ./site/config.php.old ./site/config.php mv ./site/assets/cache.old/ ./site/assets/cache/ mv ./site/assets/logs.old/ ./site/assets/logs/ mv ./site/assets/sessions.old/ ./site/assets/sessions/ mv ./site/assets/installed.php.old ./site/assets/installed.php And here is my zip_exclude.lst file, referenced in the "zip" command above. You may not need anything other than the "*.old" and *.old/*" in yours. But I'm running on a Mac and use VIM, so most of these clear up potential files related to those. .DS_Store *.DS_Store *.old *.old/* sess_* *.cache *.swp *.sh Thanks for using it! Ryan

I was just testing out this screencast service that I saw Apeisa's been using, and made a little screencast demonstrating installation and use of your GMap module. http://screencast.com/t/IaCFikQwn

Abu, Thanks for your post... this is really good info, and I'm impressed by your understanding of the language differences. I don't have a good understanding of these issues, so this is very helpful. You'll be glad to know we're not planning to handle translations on a word-by-word basis, but rather as entire blocks/phrases. So there would be a block for "a new page has been created", and the translator will be free to re-word that in any way they see fit. Want to help with the Italian translation sometime in the future? Thanks, Ryan

Hope you don't mind, but I added some stuff to your GMap module for fun. I modified it so that it has a field configuration option for "add markup automatically". So if you check that option on the field, then you don't have to add any code in your template other than this: <?=$page->map?> In the above, snippet, you would replace 'map' with your map field name. The updated file is attached. I think this is what you were trying to do before when we were writing in the other thread, so I figured it would be worthwhile for me to add it, in case it helps to demonstrate how. Another thing that I think would be cool is if there was a configuration option for it to pull an address from some other text field on the page. Then it would geocode and save it, so that it doesn't have to geocode again. Though I'm not yet sure how to do that, so just thinking... Thanks again for your work in putting this module together. This is something I will definitely use. Edit: Accidentally left a debug "echo" statement in the previous module, so have replaced it with a new version. GMap2a.zip

Looks like some good ideas that Facebook is on to there. I like what they are doing with it. But it looks like it's still JS based, and any solution that is JS based has little value for building your site's content for search engines. Unless they provide an API to it where you can render the comments yourself. But I kind of doubt that Facebook is providing that here. I'm also curious who owns the comments. Something tells me Facebook has a 50-page disclaimer about this. But these JS widgets are handy and easy to implement... I would think that sooner or later Google is going to have to start indexing pages with JS rendered content. Otherwise this is all a big black hole to search engines.

That is interesting that the apache charset was affecting this. I did just add a $config->dbCharset option that should be set to 'utf8' on new installations (and now is by default). This ensures that PHP is talking to MySQL with utf8 even when it's not the system default. However, this is probably something you wouldn't want to enable on an existing site if it wasn't already utf8. But if you perform a new installation of ProcessWire (from the latest commit) I'd be curious to know if this helps to resolve any of the issues you experienced. Btw, your PHP version is fine. 5.2.12 is newer than 5.2.4 (ProcessWire's minimum requirement) so you are all good with the PHP version.