Robin S

Works okay for me, although I always use the directory option rather than ZIP because I'm exporting/importing locally.

1. Are you creating these new pages via the PageTable field? (As opposed to creating a new page via the tree). 2. Have you specified "Table fields to display in admin" in the field's Input tab?

You can also use page IDs in a $pages->find() selector... $ctas = "1234|1235|1236"; foreach($pages->find("id=$ctas") as $p): ...but $pages->getById() has the advantage that the resulting PageArray preserves the order of IDs as you supplied them.

Thanks for the answers @kongondo. Both Media Manager and Visual Page Selector look like useful and clever modules, although the cost/features ratio favours MM. I think what would be really fantastic is something in between the feature set of MM and VPS, and this could perhaps be accomplished by borrowing some of the features developed for MM into VPS. To explain, something I think PW is missing is custom fields for images (and I'm not alone: this GitHub request from today has 4 upvotes in 2 hours). There are loads of use cases for this, but one example: you are using images in your site that have a Creative Commons Attribution license. To fulfill the terms of the license each image needs the following fields attached: Author (text), Source link (URL), License (Page select), License link (URL, although in fact you'd probably store the URL for each license in the License page field). The ImageExtra module only supports textarea custom fields so it's not the right solution. What would work is a page-per-image approach with the custom fields for the image stored in the image's page. VPS is a big step towards making this a workable solution, but to use this as a replacement for a standard image field some extra features are needed beyond what is currently offered... 1. There needs to be an easy way to edit the image's custom fields from the Page inputfield. A modal link to Page Edit is all that's needed to begin with - this is something that's possible with existing inputfields such as AsmSelect. Somewhere down the line this could maybe be enhanced with AJAX loading of the custom fields into the list view of VPS, as per repeaters (just dreaming here). 2. There needs to be an easy way to add an image (page) from the inputfield. This is possible with most existing Page inputfields if the template and parent for allowed pages is defined. Basic support for this would be to open the Add Page form in a modal (the Page Field Edit Links module does something like this). But to be a closer match to existing image field functionality it would be nice to be able to upload multiple images at once. This feature is in MM - could it be added to VPS? (when template and parent are defined for the field). 3. There needs to be an easy way to embed an image into CKEditor. This feature is in MM - could it be added to VPS? Really keen to hear your thoughts on this. Thanks!

Hi @kongondo I have a few pre-purchase questions: 1. Is a PW3-compatible version of Visual Page Selector very far off? How about Media Manager - is that PW3-compatible? 2. Could you say a bit about how the use cases would differ for Visual Page Selector versus Media Manager? They seem similar in many ways (or similar in terms of image management - I know that MM supports more than just images). 3. Media Manager includes an upload feature to go from image files on my computer to page-per-image pages in PW. Does Visual Page Selector have a similar upload feature? If not, how do you recommend images are loaded to pages? 4. One of the main things that appeals to me about the page-per-image approach used in VPS/MM is the ability to add custom fields to the page used to hold the image. But I saw that you commented in the MM thread: So would VPS be a better option if the editing of custom fields is needed? 5. The demo video for VPS doesn't show if the page holding the image may be opened for editing from the VPS field. In other words, can I click the thumbnail or image title and open the page? Does it open in a modal window? Thanks, Robin.

My first time using this module - very cool. For custom "additional" fields it would be nice to be able to set a field label as well as the field name, so field labels in the page editor can have spaces instead of underscores, etc. Maybe the field labels could be defined in the same table that is used for selecting TextFormatters?

Hi @tpr - would you mind updating the module to fix the deprecated constructor? Thanks.

Yes, that would work. Even without Soma's module there is a checkbox for clearing the cache in the config of the PageRender module. Or use a simple function/module/snippet to clear just the pages that use the particular templates you worked on, e.g. function clearCache($tpls) { $p = new \ProcessWire\Page(); $pgs = wire('pages')->find("template=$tpls"); wire('modules')->PageRender->clearCacheFilePages($pgs, $p); } clearCache('basic_page|home');

That's strange. I have the latest Tracy and PW versions, and if I introduce a deliberate error into home.php I get this:

Hi @adrian, Apologies if this has already been asked and answered before. When using the "Editor Protocol Handler" feature, the linked error is often to a file in the file compiler cache, e.g. "...\assets\cache\FileCompiler\site\templates\home.php". But to correct the error you actually want to open "\site\templates\home.php" for editing. Would it be possible to rewrite links to compiled files so they point at the original uncompiled file instead?

Hi @horst - this module is great and I use it regularly. Only problem is that it causes a deprecated constructor notice in PHP7 (class "filo" has a method "filo" rather than "__construct"). Would you mind updating it? And maybe submit it to the modules directory too? I could update it for my own use but it would be cool to have an "official" version.

It's not so much that I'm intentionally using caching in a development environment. It's that I have many small (and small-budgeted) sites where it isn't economic, or really necessary, to maintain and sync independent dev/staging/production environments. So it's not unusual for me to make small template changes directly on the live site, where the issue is that changed CSS and JS files may be loaded before the corresponding HTML changes flush through the cache. Having said the above, I do take the point that it's probably not a situation that justifies any changes to Template Cache or ProCache. It might be possible to avoid a recursive modified time check by detecting changes with an inotify script (thanks to @netcarver for the reminder), and I'm going to explore that out of curiosity, but the simplest and best solution is just to remember to manually clear the cache after making template changes. This by itself does not clear the template cache - you would still need to clear the cache for any pages using templates you have modified. Otherwise when you set... $config->disableTemplateCache = false; ...after making template changes PW will serve the old cached pages that exist from before template cache was disabled.

@thetuningspoon, Ryan has suggested that an alternative is to hook InputfieldWrapper::renderInputfield See his GitHub comment.

When you see all the new features listed together and consider the short amount of time this has happened in it's really impressive. Thank you Ryan, and thanks also to the other contributors to the PW core.

@Fantomas, welcome to the PW forums! I found your post difficult to follow because of the page names you have used in your example. It would be easier to grasp what you're trying to do if you use demo names that can have some meaningful relation, e.g. "Cars", "Model", "Colour", etc. The thing you're asking about is not the basic inputfield dependency feature that this thread introduces, but is actually a feature of Page inputfields. The trouble is that the feature is not formally documented anywhere (grumble, grumble) - it just pops up in forum discussion - so it's difficult to know exactly what is and isn't possible in terms of this feature. As I understand it, the feature only works in the "Custom selector to find selectable pages" (not in "Custom PHP code to find selectable pages") and the reference can only be to another Page field that is in the page being edited. If you're wanting to reference the value of a Page field on a different page then you can do this with FieldtypeReference (and maybe RuntimeMarkup also, not sure).

Thanks @LMD - I guess what I was driving at is that ideally a cache will clear automatically whenever it becomes out-of-step with the state of the live site, without any manual intervention necessary. If we identify situations where the cache is not automatically cleared when it's desirable that it does clear (changing a template or a template file, maybe other situations too) then maybe new features to deal with those situations could be added to Template Cache / ProCache.

Not sure I understand. Do you mean when you add a new page, in the first step where you select a template for the page you are seeing the templates of repeaters included in the list? That shouldn't be happening because the repeater template (which is only visible if you choose to show system templates in Setup > Templates) should be set to "Can this template be used for new pages? No". Edit: I think I get what you're talking about - you can select a repeater template in a page's "Settings" tab. The answer to that is "just don't" . A repeater does create a (system) template to use for its repeater pages, but not multiple templates which is what I thought you were saying in your first post.

Just to confirm - you can use CKEditor in normal "Regular Editor" mode, and it's only if you change to "Inline Editor" mode that a problem occurs? I just tried CKEditor in inline mode in a fresh install of PW 3.0.35 and it worked normally so I think it must be something specific to your environment rather than a PW bug.

I can confirm the behaviour in PW3. I think it's a bug - will you raise a GitHub issue for this?

I don't experience this problem with this module - for me only email addresses are obfuscated, not twitter handles. name@testing.com <- this would be obfuscated @testing <- this is untouched

Not a proper answer to your issue, but have you had a look at MarkupSimpleNavigation? It will take care of your current/parent classes, plus a lot more (if you want it).

$my_options_field->inputfieldClass = 'InputfieldCheckboxes';

Besides the hidden admin page approach, you could use a module config page to return the AJAX data. You would need to have an additional module because an inputfield module doesn't autoload. So your module folder consists of: TestAjax.module InputfieldTestAjax.module InputfieldTestAjax.js TestAjax.module <?php class TestAjax extends WireData implements Module { public static function getModuleInfo() { return array( 'title' => 'TestAjax', 'version' => '1', 'summary' => 'Installs and is used by InputfieldTestAjax.', 'installs' => 'InputfieldTestAjax', 'autoload' => "template=admin", ); } public function init() { $this->config->js('admin_url', $this->config->urls->admin); $this->config->js('module_name', $this->className()); $this->addHookBefore('ProcessModule::executeEdit', $this, 'ajaxResponse'); } public function ajaxResponse($event) { if(!$this->config->ajax || $this->input->get->name !== $this->className()) return; $event->replace = true; $data = '{}'; if($this->input->post->test_ajax) { $test_ajax = $this->input->post->test_ajax; // populate $data } $event->return = $data; } } InputfieldTestAjax.js $(function() { var test_data = { test_ajax: 'my string' }; var url = config.admin_url + 'module/edit?name=' + config.module_name; $.ajax({ url: url, data: test_data, type: 'post', success: function(data) { alert(data); }, error: function(jqXHR, textStatus, errorThrown) { console.log(textStatus, errorThrown); } }); }); InputfieldTestAjax.module ...whatever you need for the inputfield.

I get the same issue as the OP when doing a new PW install with a profile saved by the ProcessExportProfile module - often I'll see module errors or warnings until I refresh the module cache. Doesn't really bother me as it just becomes part of my routine when doing a new installation, but it would be nice to cut out this step.

@LMD, could you explain the situations when the template cache is not automatically clearing on your dev site when you would want it to? I'm just curious because I have never really used the template cache options and have always used ProCache instead. It would be good to know what things to be aware of if using template cache. Thinking about situations when one would want the template cache to clear automatically... 1. Page save: cache can be automatically cleared for the saved page and any other pages using options in the template settings. 2. Changing page sort order: cache is not automatically cleared (according to this thread). 3. GET or POST variables present: cache can be automatically cleared using options in the template settings. 4. Adding/removing/changing fields in the template: not sure, is the cache cleared automatically? 5. Making changes to a template file: not sure, is the cache cleared automatically? Any other situations when the cache should clear?