ryan

That's what I'm wondering too. My best guess is that he's expecting business-industry to be urlSegment1, but business-industry is actually the name of the page.

Assuming those 3 result in identical results, most likely the 2nd one would be fastest since it is 1 API call rather than 2. The 1st one would be the second fastest since $page->children() is faster than $page->find, as it doesn't have to consider hierarchy beyond 1 level. These are my best guesses anyway. If you want to test them out, take a look at Debug::timer() (/wire/core/Debug.php). Also note you'll want to use double quotes for your selectors as the $date variable would not be dereferenced in single quotes.

What module is that? I don't remember this one… though less sleep lately around here takes its toll on memory. Is this a custom module you've developed?

You could either add a comments field to basic-page, or add an if() check to make sure the page has a comments field before attempting to call ->count() on it. i.e. if($page->comments) { $numComments = $page->comments->count(); } else { $numComments = 0; }

Have you checked to see if any JS errors are occurring? Since the top save button is started up via JS, it makes me wonder if some JS failed (perhaps from PageEditFoldStatus) and prevented execution of the code that initializes the top save button.

Glad you found the solution there. I've also resolved strange PHP issues in the past by clearing the opcode cache (APC), and/or restarting Apache, and that seems to do the trick. Though in this case, I'm guessing that your mysqlcheck reset something that fixed it. Some index must have been broken or not working quite right.

It looks to me like PW must not have "ALTER TABLE" permissions to the database. That's the only thing I can think of that would cause that error. Can you double check and let me know? Though I'd also be curious to know what PHP and MySQL version you are using, and if there were any other hiccups during the install process?

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]