Robin S

Thanks for the reply; no hurry at all. Am currently getting by using PageTable for page-per-image images, and when I get time I will explore Inputfield Selectize also as that looks like it would be good for the task. One last question for now: do you offer an upgrade path for your commercial modules? That is, if I purchase a Single license and find that I love it and want to use it on all my projects can I pay an upgrade fee to move to a Developer license?

I suggest using phpinfo to compare settings between the old and new server.

I am pretty happy with this solution - works for me anyways! Myself, I add SmartyPants and HTML Entity Encoder textformatters to all text fields.

I understand the thinking here, but agree with @adrian that often you want a single line input rather than multi-line. I know you want to avoid an overly-complicated interface but perhaps there could a "Rows" input for additional fields like for the Description field?

Are you running the same PHP version on the new server? Any differences in PHP settings? post_max_size and upload_max_filesize would be ones to check in particular. Another thing to do is open your browser JS console and look for errors during file upload. If there's anything there you can search the forums for references to the error. This post from Ryan has some good advice, and the whole thread discusses a similar issue.

Hi @adrian, I have had a look at this and I think the problem is due to the direction of file path slashes on Windows versus Unix. You can see mixed forward and backslashes in this screenshot of the Template Resources panel. It looks wrong but the links to the editor still work okay. Edit: apparently it's no big deal to mix forward and backslashes within a path for Windows. In terms of the error notice links containing paths to the file compiler cache, this is because having the slashes around the wrong way prevents the str_replace in Helpers::editorMapping from replacing the necessary section of the path. I got the links to work by adding the following after line 303 in TracyDebugger.module $compilerCachePath = str_replace('/', '\\', $compilerCachePath); Of course this is not a real solution. But maybe there is some cross-platform way to deal with file paths?

Sussed it after finding your discussion with Ryan in the Form Builder subforum. $this->addHookAfter('ProcessFormBuilder::getInputfieldPageClasses', function($e) { $classes = $e->return; $classes[] = 'InputfieldPageDependentSelect'; $e->return = $classes; }); Would be good to include this in the readme seeing as it mentions that the inputfield is a good addition to Form Builder. Or the hook could be done in a dependent autoload module that comes included with InputfieldPageDependentSelect? Thanks for making this cool module!

@LostKobrakai I'd like to try your InputfieldPageDependentSelect module in Form Builder but I can't work out how to get the inputfield to show up. I can use it for Page fields in the PW admin, but I can't select it for Page fields in Form Builder. Normal page field: OK Form Builder page field: missing It's also not available for selection in the Form Builder module config field: "Inputfield types to use with Form Builder". Can you see where I'm going wrong? Thanks. PW v2.7.2, Form Builder v0.3.0

That looks a bit strange to me. You are saying data is an array where the first value is the string 'notices' and the second value is the WireArray $notices - is that intentional? Or do you maybe mean: $data = array('notices' => $notices);

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: