ryan

I'm guessing you are on the dev branch? There is a bug. I'll update the branch here soon (have to test some other stuff), but if you are on the dev branch and want to fix, here is a patch for file /wire/modules/Fieldtype/FieldtypePage.module. You'll want to replace the "-" line with the "+" line below: @@ -223,7 +226,7 @@ class FieldtypePage extends FieldtypeMulti { * */ public function ___formatValue(Page $page, Field $field, $value) { - if($page->editable() || !$field->allowUnpub) return $value; + if($field->allowUnpub) return $value;

Thanks guys I've setup this one to redirect to processwire.com

I'm just wondering if suppressing the warnings here is a good idea because this is an error condition that should probably be reported? The !is_file($file) return; is already in the parseFile() function that execute() calls, but that one isn't geared towards error suppression. I'm not sure I totally understand the conditions you ran into or why the errors should be suppressed here, but maybe a screenshot (or even pasting in the warnings) would clarify?

I almost never pull pages by ID. The whole readability factor of $pages->get('/path/to/page/'); is well worth the compromise for me most of the time. But it's true that using ID is more bulletproof because it'll keep working even if you later move the page. But I usually choose readability (and I don't move stuff around very often).

Great site! Beautifully put together. Thanks for posting.

Really great site! Nice work. Thanks for the ProcessWire mention on the credits page too.

You don't need "check_access=0" if you are using "include=all", because "all" implies everything. You'd only use "check_access=0" if you wanted it to include pages that the user didn't have permission to view, but still wanted to exclude hidden pages. I think what you are probably looking for is "include=all". You need quotes around "pages", i.e. wire("pages") I don't understand this line–it looks a bit unusual for a selector, so wondering if there might be a problem there. This should be: $pages->find($selectors);

Where does this bit of a code appear? In a function, or out in the main body of the template file? I ask because I see $input and wire('page'). If this is within a function, then you need to be using wire('input') rather than $input. It's feasible that if you've got error reporting turned off you might not notice if $input is out of scope and undefined. Another possible consideration might be if you are rendering a page within another page. There doesn't seem to be indication that's taking place here, but something to consider just in case.

You might try to see if you can get another plugin working. I seem to recall that we saw issues with some TinyMCE plugins where paths were hard-coded in the module so that they wouldn't work unless they were right in the TinyMCE main plugins folder. I think CodeMagic had this issue.

Really impressed by all you've put together here Horst, nice work!

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');