ryan

You may want to set $select->required = true; so that there isn't an unselected option. Rather than removing all the options and adding them back, you should just be able to set the 'value' attribute to whatever you want the selected option to be: $select->attr('value', $selected_page_id); Note that "kg" is your label rather than the value, so you are going to know the ID of the page with name/title "kg" in order to make it selected.

Btw, this might be a good place to mention that PW 2.3 dev adds a new Page::getUnknown hook (soon to be committed). That function gets called whenever a field is accessed that didn't resolve to anything. So you could [n the near future] do this (below) and you could call $page->some_radio_button_group on any page (specifically those that didn't already have the field) and have it resolve to what you want to. wire()->addHookAfter('Page::getUnknown', function($event) { $page = $event->object; $name = $event->arguments(0); if($name == 'some_radio_button_group') $event->return = new NullPage(); });

The some_radio_button_group field is a field of type Page I'm guessing. Since fields are bound to templates, and templates are bound to template files, you shouldn't have to check that the page has a some_radio_button_group field. That is, unless the code is independent of the template (like for shared functions across different templates). But if we can assume your template file knows what template it's dealing with, then you would want to set your Page field settings "details" tab to be dereferenced in the API as "Single page (Page) or empty page (NullPage) when none selected". That way your $page->some_radio_button_group->value; would result in a null (blank) even when the field has no value.

I'm not sure that a 404 page should be localized since it's responding to a URL that doesn't exist and thus has no language. Though you could potentially detect the language from your 404 page template by having your code look at the $_SERVER['REQUEST_URI'] for something that clarifies the language. Even better may be to have your code look at the $_SERVER['HTTP_REQUEST_LANGUAGE'] and set the $user->language consistent with that before rendering.

I'm not sure I totally understand the issue and might need a little screengrab/video to see exactly what you are talking about. But any javascript errors occurring in your JS console? It sounds like there would be two modals on top of each other here, and wondering if the targets are getting mixed up.

Curly quotes are working for me here at least. Though I do have to type them in as “usual” – option-[ and option-shift-[, or paste them in. Anyone else able to reproduce? Are you sure it's not just a typeface style (or lack of it?). For example, the quotes I entered around the work “usual” above are curly quotes in the editor here, but apparently the font the forum uses to render them uses the same glyph for both open and close quotes, making it appear they aren't curly quotes.

We're happy to host any *.processwire.* stuff on the main server here.

I have no idea why $_GET['q'] would be missing from the request when you specified it, but the only thing I can think of is if your request possibly resulted in a 301 first that went by unnoticed? This could happen if you specified the URL without a trailing slash in your <form action> attribute. In modern versions of MySQL it seems there isn't much difference even when you get into thousands of records. I suspect the real difference starts showing up in the hundreds of thousands to millions of DB records to search.

I don't have enough experience with this module to answer the question, but wanted to bump this question back up. I think Adam may be the best one to answer since he wrote the module. You may want to send him a PM too, just in case he's busy he might not see this thread.

I'm not enough of a Javascript expert to say for sure here. But I do know that jQuery provides some pretty reliable functions for this use: $(window).width(); // returns width of browser viewport $(document).width(); // returns width of HTML document No need to worry about session IDs with ajax requests. The server and browser are all handling this behind the scenes in the same way they do with a regular request.

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.