ryan

Nothing jumps out in the code to me. Double check that you have "allow page numbers" enabled in your template settings for whatever template your $page is using.

I'm wondering where the '/var/www/' is coming from? I'm guessing that it's being interpreted as a relative directory and expanded. Either way, I think the session.save_path probably needs to stay set to whatever the server default is. FYI, this is what I've updated that line to in /index.php (in my local dev branch) and you may want to make the same change in yours: if(ini_get('session.save_handler') == 'files') ini_set('session.save_path', rtrim($config->paths->sessions, '/')); Hopefully what will happen there is that the session.save_path call will get skipped entirely, leaving it set to server default (which I'm assuming is tcp://localhost:11211). However, if it isn't, you can perform your own ini_set() call in /site/config.php: ini_set('session.save_path', 'tcp://localhost:11211');

Placing your translatable text in __() function calls is the recommended way to go. It's also the way that PHP gettext() works (though it uses _() rather than __()) and is a universal standard. If you want to keep all your translations in a single file, then that's certainly fine. But I think that's ultimately creating more work for yourself as you end up having to refer to translated text via keys rather than the actual text. The only situation where I might use keys are if I need to re-use the same phrase multiple times, across multiple templates… which would save having to translate the same text more than once.

Works great for me–awesome tool Soma! I have added a note about it to our download page: http://processwire.com/download/ It looks like the domain forwarding service I'm using (Namecheap) won't let me add redirects for anything other than www and @. So I can't add a dev download just yet. But I'll plan to add a dev.grab.pw or grab.pw/dev once I move the DNS.

I'm not aware of a way to control the order and agree it does seem somewhat random. I would assume it's got something to do with the order that they were zipped into the file, but not positive.

This is only something you have to consider if going from a PHP version 5.3.x or newer, and migrating it to a site running PHP 5.2.x. You wouldn't run into this issue going from say PHP 5.4.x to 5.3.x. Also keep in mind that PHP 5.2.x was EOL'd more than 2 years ago. Any servers running PHP 5.2.x need to be upgraded very soon, just as a matter of security. ProcessWire 2.3 is the last version to support PHP 5.2, as PW 2.4 will require 5.3.8 or newer.

removeAll() is a method of a PageArray not a Page. So I think your code will need to check what type it's dealing with in order to avoid that error. if($reset) { if($page->$name instanceof PageArray) $page->$name->removeAll(); else $page->$name = null; }

Sounds like you found a good solution there. I just wanted to mention one alternative that I've used before too, just for the sake of discussion. You can add this to your .htaccess file: AddType application/x-httpd-php .cfm That will make files ending with ".cfm" get run by PHP. Then you could create this file: /store_item_detail.cfm require("./index.php"); // bootstrap ProcessWire $itemID = (int) wire('input')->get->item_ID; if($itemID) { $item = wire('pages')->get("template=product-legacy, legacy_item_id=$itemID"); if($item->id) { // now you can either render the page… echo $item->render(); // …or if you prefer, redirect to it: wire('session')->redirect($item->url); } else { echo "Unknown item ID"; } } else { echo "No item ID specified"; } There you have it–ProcessWire powering ColdFusion scripts.

I agree with Wanze. But if you have a need to make the pages completely inaccessible (via access control), you can always remove guest access at the template level and use "include=all" or "check_access=0" when you need to retrieve them. But if "hidden" will accomplish what you are trying to do, I would use that, as it's more in-line with what it was designed for. Also, minor corrections to Wanze's code: // In your template file if (!$user->isSuperuser()) { // Changed from SuperUser to Superuser (case) throw new Wire404Exception(); } // OR if (!$user->hasRole('superuser')) // changed superAdmin to superuser

Chances are there were duplicate rows. Check what column you are assigning to your 'name' field of the page and see if there are any duplicates in your CSV. If the CSV import module comes across the same one, it'll attempt to update the existing one already there rather than add a new one.

I'm not sure why it won't let you change the language for the guest user, but I'll look into it. However, I recommend aligning your guest user with the default language. The default language is specifically meant to be "whatever language is the default when the user hasn't selected one", in the same way that the guest user is mean to be a placeholder for when no user is present. As a result, the guest user and default language should ideally align. The default language can be whatever language you want it to be... there's no requirement that it be English or anything like that.

I understand the convenience, but I don't think having separate core downloads for PW depending on language (or other factors) is sustainable from a version or security standpoint, so would rather avoid that by always having the core download be directly from our GitHub. But having clear additional download links for language pack, docs, etc., to accompany the main download link would be great. Longer term, we'll have an automated download function that can bundle modules and language packages automatically at runtime.

If that fixes the issue, I'll add a line to our core /index.php that only applies the session.save_path if the session handler is 'files'.

I'm not really sure about this one. What inline styles are on the table? I'd probably prefer not to have any inline styles there. But tables don't always obey the rules. If the content is larger than what the table can contain, I think browsers may not always be consistent in how they handle the situation regardless of what styles are applied.

This option may be coming in the future.

I think that once the HTML5 datepickers across all major browsers reach a level of maturity where they are as good or better than the jQuery UI one, this makes sense. Though how does the HTML5 datepicker support multi-language and various date formats? Currently, we are translating custom date formatting strings between PHP and javascript. Does the HTML5 datepicker support time input too? I guess I have to read up more on the HTML5 date picker, but am wondering if the multi-language aspect especially might present more challenges in HTML5 than javascript.

Pogidude, you are correct in all of that.

For stuff like this, I would be more inclined to use an Apache rewrite rule, just because there would be less overhead and code to make it happen. Something like this might work in your .htaccess (somewhere after the "RewriteEngine On" line): RewriteRule ^(continent[0-9]+)/(land[0-9]+)/(project[0-9]+)/donation/?$ /stuff/donation/$3/$2/$1/ [R=301,L]

Awesome work Horst!

I think it's probably just whatever you find most useful in your situation. But my preference is usually to sanitize on first access, unless I potentially need an unsanitized version to determine how it should be sanitized (which might be the case here). You could sanitize first with pageName (which sanitizes to [-_.a-z0-9], and then use ctype_digit to determine if it's an integer or string: $value = $sanitizer->pageName($input->post->something); if(ctype_digit("$value")) { // it's an integer $value = (int) $value; } else { // it's a string }

Name is a consistent term used throughout ProcessWire and also the term used at the API level, so I'm not sure it's necessary a good idea to change it (or at least it might be confusing). But I'm guessing it could be done by way of a hook after ProcessPageEdit::buildForm: public function hookBuildForm($event) { if($event->object->getPage()->template != 'user') return; $form = $event->return; $field = $form->get('_pw_page_name'); $field->label = 'Username'; } As for "page name in address bar", I don't think that we ever actually use the the name in the address bar for users since there is no /site/templates/user.php by default. So I'm confused on that one.

If you've got a situation where you are having to do something repetitive (like the image selection and placement you've mentioned), then look at breaking it down further. Images manually positioned in copy (via TinyMCE) aren't ideal, and are better for one-off or unique situations. It's better to standardize on dedicating a specific image field (i.e. featured_image) to be a method of automatically connecting an image with a page. There are also situations where you may find it helpful to associate images with page references. For instance, a blog post with categories might have the categories each have an image that gets automatically pulled in and displayed when the blog post is rendered.

If I understand it correctly, it looks alright to me. We've done things like this before, connecting the user name with another page though rather than having a saperate "username" field, we just used the existing page "name" field to connect with the username. So that's the only thing I'd say, is to double check that you really need an extra "username" field, or if you can make use of the built-in name field to do all this.

I'm not sure I understand this case. The error you are getting is what I'd expect if the LanguageSupportPageNames module wasn't installed. But since it is installed, it's a bit of a mystery there. I'll see what I can do in trying to reproduce it. But you do have an alternative to the localUrl() function, and that is to just set the user's language for each iteration of your $languages loop, and then call $page->url: $saved = $user->language; // save user's language foreach($languages as $language) { if(!$page->viewable($language)) continue; $class = "$language" == "$saved" ? " class='active'" : ''; $user->language = $language; echo "<li$class><a href='$page->url'>$language->title</a></li>"; } $user->language = $saved; // restore user's language

If the internal server error is coming from ProcessWire (as opposed to Apache), then you can enable debug mode or check your /site/assets/logs/errors.txt to see what the actual error message is.