Robin S

Custom Inputfield Dependencies A module for ProcessWire CMS/CMF. Extends inputfield dependencies so that inputfield visibility or required status may be determined at runtime by selector or custom PHP code. Overview Custom Inputfield Dependencies adds several new settings options to the "Input" tab of "Edit Field". These are described below. Note that the visibility or required status of fields determined by the module is calculated once at the time Page Edit loads. If your dependency settings refer to fields in the page being edited then changes will not be recalculated until the page is saved and Page Edit reloaded. Usage Install the Custom Inputfield Dependencies module. Optional: for nice code highlighting of custom PHP install InputfieldAceExtended v1.2.0 or newer (currently available on the 'dev' branch of the GitHub repo). The custom inputfield dependencies are set on the "Input" tab of "Edit Field". Visibility Show only if page is matched by custom find Use InputfieldSelector to create a $pages->find() query. If the edited page is matched by the selector then the field is shown. Show only if page is matched by selector As above, but the selector string may be entered manually. Show only if custom PHP returns true Enter custom PHP/API code – if the statement returns boolean true then the field is shown. $page and $pages are available as local variables – other API variables may be accessed with $this, e.g. $this->config In most cases $page refers to the page being edited, but note that if the field is inside a repeater then $page will be the repeater page. As there could conceivably be cases where you want to use the repeater page in your custom PHP the module does not forcibly set $page to be the edited page. Instead, a helper function getEditedPage($page) is available if you want to get the edited page regardless of if the field in inside a repeater or not. $edited_page = $this->getEditedPage($page); Required The settings inputfields are the same as for Visibility above, but are used to determine if the field has 'required' status on the page being edited. https://github.com/Toutouwai/CustomInputfieldDependencies http://modules.processwire.com/modules/custom-inputfield-dependencies/

The problem with redirecting back to the Lister is that you will lose your current page in the pagination and any filters that were applied, which IMO would be pretty annoying. The nice thing about the modal editing is that everything is just as you left it after you save.

Lister Pro has an option to edit links in a modal window. If you don't have Lister Pro I think it would be possible to turn the edit links of the core lister into modal links with a hook or JS. Edit: for non-Pro lister you can make edit links modal using Admin Custom Files. Enable for process "ProcessPageLister" and add file "ProcessPageLister.js"... $(document).ajaxComplete(function(){ var $a = $('.PageListerActions .PageEdit').not('.PageAdd'); $a.addClass('pw-modal pw-modal-large'); $a.attr('data-buttons', '#ProcessPageEdit > .Inputfields > .InputfieldSubmit .ui-button'); });

Check out Profields Table, Repeater or Profields Repeater Matrix, PageTable (can't find a good link for this but it's an installable core module).

Hi Adrian, I have a module that could be helpful here - just putting the finishing touches on it and will release this weekend. Cheers, Robin.

A repeater will work, but it's sort of overkill for repeating just a single line of text. Behind the scenes it is creating a page for every line. This is probably the way to go. If you wanted your own custom markup you could explode and foreach a textarea. $lines = explode("\n", $page->my_textarea); if(count($lines)) { echo "<ul class='my-special-list'>"; foreach($lines as $line) { echo "<li class='my-list-item'>$line</li>"; } echo "</ul>"; } For sure, and for more complex repeatable items see the Table fieldtype.

I assume that when you say parent and child you are talking about pages. If you need to edit the fields of the child pages directly in the listing then you could use Lister Pro for viewing the children list and editing the fields using the inline AJAX editing feature: https://processwire.com/blog/posts/inline-ajax-page-editing-comes-to-listerpro-processwire-2.6.6/ If you just need to show the fields from the child pages then you could generate a table from the child pages using Matrix or RuntimeMarkup.

Not to put you off making your module, but I believe RuntimeMarkup can do this.

I did a bit of a test. I'm using delayed output with an auto-appended "_main.php". I created a different append file "_main_index.php" for the purposes of rendering the index field: just echos the region variables without any HTML elements. Then in /site/ready.php... $this->pages->addHookAfter('saveReady', function($event) { $page = $event->arguments('page'); if($page->template->name !== 'basic_page') return; $page->index = $this->sanitizer->textarea($page->render(null, ['appendFile' => '_includes/_main_index.php'])); }); All works well, no errors or multiple calls to the hook when saving from the admin or the API. Maybe it's the fact that I'm hooking after saveReady that make the difference. Edit: hooking before or after saveReady should make no difference. From the hook docs...

Just realised that 'modal=1' is hiding the header/footer with CSS rather than different markup being rendered. So easy enough for me to add some CSS to hide the notices too. #notices { display:none; }

I'm working on a module that needs to load a page inside an iframe (inside a CKEditor dialog). Currently I am loading a plain HTML file and doing all the processing with Javascript, which works fine. But I'm wondering what options are available to me if I wanted to load a PHP/API-powered page in the iframe. PHP files cannot be directly loaded inside /site/, so I thought about the following options to work around this. I'm keen to get any advice about which would be best and any other solutions. 1. Have my module copy a PHP file to the root directory, where PHP files may by loaded. This file could then bootstrap PW. This option seems messy - I don't think it's good for a module to copy files to the root. 2. Make a Process module that creates a hidden page under Admin. The problem I'm finding with this is that it's difficult to avoid visible admin template elements being rendered in the page. This is similar to what @blynx was asking about here. I can append 'modal=1' to the URL to avoid the admin header and footer (I think that is what @horst's modules do) but I'm finding that message notifications (e.g. compiler notifications) can still appear and I don't want them in my iframe. Is there another URL parameter (or a hook maybe) that I can use to prevent notifications? 3. In the install() method of my module, create a new template and a new page and assign the template to the page. I wouldn't want my template file in the /site/templates/ directory but I figure there is a way to assign a template file that is inside my module directory. This option seems like it will work, but it involves more code for the page/template creation and deletion on uninstall than the elegance of the automatic page options for a Process module. 4. Some kind of hook to page render that prevents the normal admin template markup and outputs my custom markup instead. I guess with this option I wouldn't even need a page - just look for some GET variable in the URL. Would this be a good solution? Any other suggestions for how I can load a clean page with access to PHP and the PW API? P.S. It isn't a negative for the loaded page to be using the admin template if I can find a solution to the notifications issue as part of the objective is to use the jQuery version and inputfield styles that come with the admin theme.

Just curious: do you need this index field to achieve some functionality or are you using it to optimise search performance? Just wondering why you wouldn't include all the fields you want to search in your selector instead of merging fields into the index field. In terms of dealing with the URL segments, I suppose if you have a detail view that uses a /detail/ URL segment and you think that is the view the visitors will want then you could append /detail/ to the link hrefs in search results for pages with that template.

Could it be that the host is running some maintenance task on a regular basis that makes the file system unwriteable? Of course that shouldn't happen, but at this point if you're willing to try anything you could copy the site to a different host and see if the issue still occurs. I guess you would need to simulate browser traffic for testing - I don't know much about that, maybe JMeter?

I'm not sure what could be causing the 500 error. The Apache/PHP/PW error logs might shed some light. If this is happening on a live site then it could even be caused by mod_security - turn that off if you can or check with your host. Rather than using your parseContent function you could consider rendering the page with a different template that is created with the index field in mind. $page->render($filename); // $filename assumed in /site/templates/ See this post: Or you could loop over the page's fields in the hook, checking for the type of each field and preparing it's value for the index field accordingly. foreach($page->fields as $field) { /* you can get the value... $page->get($field->name); ...but you'll want to treat it differently based on field type if($field->type == 'FieldtypePage') { ...etc... } */ }

I'm pretty sure Page fields are only stored as IDs in a cache field, and I expect Repeaters and PageTables would be the same. Which greatly decreases the usefulness of cache fields. Ryan has said this:

You might find the Page Rename Options module useful - you can set it to keep page names in sync with page titles when they change.

In the module info for a Process module you can include settings that automatically create a page under Admin: // page that you want created to execute this module 'page' => array( 'name' => 'helloworld', 'parent' => 'setup', 'title' => 'Hello World' ), Is there an easy way to make this created page hidden so it doesn't appear in the admin menus? Or if I need a hidden page would I have to create/remove the page in the install()/uninstall() methods? Edit: should have guessed it would be so easy... // page that you want created to execute this module 'page' => array( 'name' => 'helloworld', 'parent' => 'setup', 'title' => 'Hello World', 'status' => 'hidden', ),

Thanks, fixed in latest commit.

You would enable URL segments on the template used for "Shirts" and "Shoes". You would allow segments that match the names of your category pages and throw a 404 for anything else. For example: if($input->urlSegment1) { $category_names = $pages->find('template=category')->explode('name'); if(in_array($input->urlSegment1, $category_names)) { // build your selector to filter the products using $input->urlSegment1 } else { throw new Wire404Exception(); } } else { // show all the products }

You can use URL segments for the category name. Or a GET variable - the principle is the same but the URL segments are nicer. Look for the URL segment in your template and then use it in a selector for your product pages. If you read through Ryan's URL segments tutorial you should get the gist of it. Make your navigation links by iterating over the category options, or if you want to get fancy, just the categories that are used by products in that section.

I'm looking forward to client-side image resizing in PW. I have clients who will upload massive 24-megapixel 10MB images without a second thought. I use the "Max width for uploaded images" option but it's not working reliably because the oversized images still get through somehow (perhaps out-of-memory issues). Anyway, I was looking for a foolproof way for non-tech-savvy clients to resize images and found this: https://bulkresizephotos.com/ Images are resized client-side so it's much faster than many of the other online tools. You can resize multiple images at once and get a ZIP file back with the results. And the best feature is that you can set the tool up how you want and then generate an embeddable drag-and-drop widget, so it's super-easy for clients to use and there are no options for them to mess up. I created a Hanna Code for the widget and added it to the online documentation I supply to clients so it's right there when they need it. Could even potentially be embedded directly in the admin theme. Until client-side resizing comes to PW this is a useful stopgap.

Just count yourself lucky and stop your research now. Trust me, you're not missing much. But seriously, this is what I'm talking about. There's got to be a reason why Germany is the only country whose interest in PW reaches the threshold to register on Google Trends - any ideas?

Perfect, don't know how I missed that. Is this because the parentheses are needed as a kind of delimiter when looking for the /*NoCompile*/ comment? I often see parentheses used with include but thought that was a personal preference of the coder - like, you could use parentheses with echo if you wanted but it's not necessary. The PHP docs say that parentheses are not needed with include/include_once/require/require_once, and they are not used in the code examples there.

I am testing using: FileCompiler=? With dot syntax the /*NoCompile*/ comment works, but not without. include "./test_include.php" /*NoCompile*/; // included file is not compiled include "test_include.php" /*NoCompile*/; // included file is compiled

This makes $content empty, so when you call parseContent() it is getting an empty string. Edit: actually, because of the if() test, parseContent() isn't called at all. You don't show the parseContent() method in your code, and the problem could be there.