ryan

Batcher has saved me major time on a few occasions too. Definitely a must-have module.

I think I understand now. This should work so long as "custom_template_file" is the name of a Page reference field, and "select_value" is the name of the field that contains the exact text "article_page.html" among your page references. None of the pages returned in your results should be "hidden" unless you specify an "include=hidden" or "include=all". Now if the page pointed to by "custom_template_file" is hidden, that doesn't matter, because that's a page you are using to match, not one of the pages being returned by find(). However, if you want that behavior, you may be able to do it like this: "custom_template_file.select_value=article_page.html, custom_template_file.status<" . Page::statusHidden; You can also check if an individual page is hidden by calling it's $page->isHidden() method, or $page->is(Page::statusHidden); -- both do the same thing.

Antti and I implemented the CKEditor module for ProcessWire, but I don't consider myself an expert with CKEditor at all, yet. As far as I know, the allowed attributes are a function of the plugins being used in CKEditor. Antti may know better? But ProcessWire essentially uses an unmodified copy of CKEditor, so if you can track down how to do it on the CKEditor site, then that would apply to PW's module as well. If you find supporting a common need requires additional configuration options for the module, I'll be glad to add them.

I'm not sure about this one or exactly how to reproduce from here. But if you want to give me a login to this site and tell me what/where to click to reproduce it, I'd be happy to take a closer look. Also let me know what version of PW you are using and whether dev branch or not.

If you can do it with PHP, you can do it with ProcessWire in much less time. In this particular context, think of ProcessWire like jQuery for PHP, but with a fast scalable content management framework at your disposal. While we don't have a lot of pre-built user registration/management features on the admin/interactive side, users are themselves pages in ProcessWire, and so the entire pages API is available for you to work with them. Given that, you may find ProcessWire to be a lot more full featured with regards to the user system from the API side than other systems, even if we haven't explored it in full on the admin CP side.

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!