Robin S

I've only just now noticed you are referring to the "Sort settings for children" on the template, not the page. I have never tried that setting before and always define sort settings on the page. I tested it in v3.0.35 and it seems that although you don't get the modal warning when changing the child sort order by dragging in the page tree, when you refresh the page the sort order is reverted to that specified in "Sort settings for children". Can you check to confirm? If the lack of modal warning is a concern (it does seem inconsistent with the behaviour from the equivalent sort setting on page) you could raise an issue on Github.

It works perfectly, thanks!

Just guesses here... Perhaps you should empty all caches before making your profile backup. ClearCacheAdmin would be useful for that. If you FTP to the problem directory, do you see anything there that might be preventing the creation of the temp directory? For example, an existing directory of the same name. You could also try a more traditional migration (i.e. zip/ftp/extract files, export/import db via phpMyAdmin).

Works for me. I put x-ray into the body field on page 'Three' and got this result in Selector Test: Edit: just realised you're asking about selector values that are going through a sanitizer. Not sure which sanitizer you are using, but $sanitizer->text() keeps dashes intact.

I solved this with a hook to Fieldtype::markupValue... $this->addHookBefore('Fieldtype::markupValue', function($event) { $f = $event->arguments('field'); $p = $event->arguments('page'); $v = $event->arguments('value'); if($f->name == 'my_field' && $p->template->name == 'my_pt_template') { $event->arguments('value', $this->sanitizer->text($v)); } })

I have a field that has the Parsedown textformatter applied, and I want to include it as a column in my PageTable field. But entities are encoded (for security?) so the HTML tags are rendered literally: This doesn't look good - even stripping the tags would be better. Is there a way I can avoid the literal tags?

Your link to the topic you followed doesn't work, and I'm not sure what's in your renderPosts() function, but assuming that LostKobrakai is right and you are using $page->render() (edit: I see the render() call now), another alternative is to place this at the top of the template you render: if( empty($options['pageStack']) ) throw new Wire404Exception();

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.