ryan

Does this mean it's working now? I've read the statement over a few times and can't tell. If not, you may want to try $config->sessionFingerprint=false; in your /site/config.php (line should already be there, but needs to be changed to false).

ini_set() in config.php won't work unless you modify the index.php in the manner I mentioned. I think it's okay for you to modify index.php for something like this. Like mentioned earlier, I've already made the same change in the PW source so you'll see it in the 2.3 version soon anyway. Also for safety, be careful with any kind of automatic upgrades on a live server. I tend to only use automatic upgrade tools on dev servers, not production servers. If you've got an instance where you've had to modify the index.php, that would be a good reason not to do automatic upgrades.

Great guide Kongondo! Beyond being helpful to people familiar with MODX, I also think this guide would be helpful even to people that don't know MODX, as it introduces many ProcessWire concepts very well. Also, I'm not particularly familiar with MODX, so found it helpful in learning about MODX too. Thanks for your great work here.

We've got family in town, so I don't have to entertain kids and was finally able to catch up with the forum and some emails. Hopefully next weekend I'll be able to finish testing a giant batch of updates I've been making to the dev branch. It's become so much stuff that I've now started to worry the dev branch might become a little too "dev", since I know some are using this branch in production (including me). As a result, I've been holding off a bit so I can test more. I tried testing it out here on processwire.com and got a dreaded "class PDO not found" error (never expected that!). But ServInt is upgrading this machine as we type (sounds like I specified I only wanted mysqli before), and upgrading us to PHP 5.4 while they are at it. --Edit: Sunday afternoon? It's Saturday afternoon here.

Sounds like CSRF protection is coming into play. I'm guessing that something is interfering with your session, perhaps client side (browser plugins?). If you'd like, you can disable CSRF protection in your /site/config.php: $config->protectCSRF = false; However, I'd check your browser to make sure you don't have some kind of spyware or something messing with cookies.

I'm not sure that I totally understand the details of what you are suggesting, but as a concept I think that it's a fine idea. However the "reusable template themes" is not really the target audience of ProcessWire. Though maybe someday our audience will include this group too. But for now I think it's best to maintain focus on what ProcessWire is designed for. But I'd certainly be supportive of anyone that wants to pursue projects like this. I also think that our current site profile system will lend itself well to reusable templates for when a theme shop takes interest in developing them. The primary distinction is that PW site profiles are starting points, not themes to swap in and out.

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.