adrian

Just wanted to post a little warning here. @SteveB PM'd me with an issue he was have with a relatively complex migration. I initially tested on PW 2.5.3 and everything worked flawlessly in several tests, which is great! But then testing on the latest PW dev there were some significant issues with certain pages not ending up where they were supposed to be, so I need to look into this in more detail, but just wanted to remind you guys on dev to be careful until I figure this out. Not sure what version of PW this started happening with.

Have you tried the "Overwrite existing files" option in the field's Input tab?

There aren't any intentional restrictions on a PW site working on an older version of PHP, but if a required method etc is not available, then there will be a failure. I am surprised you didn't get a warning about it when you initially installed PW though.

I haven't looked through all your code properly, but the obvious issue first is the way you are doing file_get_contents. You need to point it to the path of the file. I think this should work: file_get_contents($page->codefile->filename); If $field->value = "test"; is working, then I think this is the only change you should need. I am curious though why you are converting a textarea field to a file and then on render getting the contents back out of that file. I am sure there is a good reason - just seems weird at first glance

Nice to see what you've been up to blad - you've been very quiet lately - now we know why. Nice job - looks like a great custom admin interface you've built! Is this a bug: http://www.grupoolmos.com/inmobiliaria/piso-bien-amueblado-en-armilla/ Looks like there is something wrong with that thumbnail slider's container width. I am on Chrome / OSX

I see that you just upped the version number in the modules directory for this module, as well as your TextformatterImageLinkInterceptor module, both to 0.1 The problem is that in Github, they are both still showing: 'version' => 1 which translates to 0.0.1 This is causing problems for PW sites when you click "Check for Updates" or you use the ProcessWire Upgrades module because they both say there is an update (because they pull from the modules directory), but then they get the files from Github which are still versioned as 0.0.1 The best option is to set the version in the file on github and then run the "Edit this Module" option in the modules directory and just submit to have it grab the new version number directly from the file - this way they will always be in sync and will prevent any issues. Thanks!

I really don't understand what you are trying to do, but does it help if you use $pages instead of $page? I am guessing those ids are just examples? Also, you don't need "id=1" just: $pages->get(1) works. $pages->get() - returns one page from throughout the page tree $pages->find() - returns all matched pages from throughout the page tree $page->get() - returns the first matching child of $page although I think $page->child() makes more sense in this case

When you have a field that is returning an array, like an images field that allows more than 1 file, you want this: if(count($page->img)) {

Yep - speedier site setup for sure! Also, with the new batch update function, it is also much easier to update all the modules on existing sites in one go. I find it can be quite tedious to update modules one by one with the current PW tools.

I like the current behavior in that you can save a page unpublished and the populated fields will be saved. Even if you try to publish, the populated fields will be saved, it's just that it won't actually publish until the required fields have been populated. But I would like the option to not show the required warnings unless the user is actually trying to publish the page. On templates with long complicated sets of fields, there are plenty of times you don't want to fill out everything right away and I think the warnings are intrusive at this point. I am thinking this would be a template level setting, but I guess it could also be per field, but that might be a little annoying to set them all? If it was per field, then it should be available as a template context override as well. Of course the title field should be treated differently. Anyone else have any thoughts on this?

Hi everyone, Just added some new features (not in the repo just yet), but wanted to get some feedback on a new name for the module. It still functions as a way to migrate modules and their settings from one PW install to another, but now also includes: batch download and install modules from a list of class names entered in a textarea field batch module updating Name ideas: ModulesManager wouldn't be bad, but already taken ModulesMigratorInstallerUpdater would be the most accurate, but obviously ugly ModulesInstaller is OK, but doesn't cover everything ModulesHelper ? ModulesToolkit ? Free like for any suggestions Here are some screenshots for inspiration: THE OPTIONS EXPORTING INSTALLING (FROM MIGRATED ZIP) INSTALLING (FROM LIST OF CLASSNAMES) BATCH UPDATING MODULES WITH AVAILABLE UPDATES

Sorry about that - yes url won't work because you need full path

I have deleted this module from the directory, but you should consider removing the link from your first post and explain to users what the alternative is.

I have deleted this module from the directory, but you should consider removing the link from your first post and explain to users what the alternative is.

Hey guys - sorry for the migrator issues here. I know that Macrura did a migration of pages with a page field that linked to users (I think that is correct). As I mention a couple of posts above, I think this is because of the way I have migrator grab and recreate the content of page fields on the destination site. Usually this isn't a big deal, but I need to change some behavior so it doesn't mess things up when linking to system pages like in this case. It's on my list to sort out!

Pete - I think the biggest issue with doing a check like you describe is if the video url field is changed to a different video. In that case you'd want the image to be changed. I think it would be manageable though - check if the existing image has a filename consistent with a video thumb and if it is, then replace it, but if not leave it because it was manually uploaded. But given that the default PW behavior would be to overwrite the existing image in the field, perhaps your manual thumbnail field is a better idea? It might even be nice to set a field dependency on the automatic thumb field such that it's only visible if the manual one is blank? However that is a different issue to respecting the maxFiles setting. I can't find much about it, but there is reference to it in soma's post here: https://processwire.com/talk/topic/3105-create-pages-with-file-upload-field-via-api/?p=30979 Should the PW core ensure this setting is respected when uploading via the API, or should it be up to us to check? Anyone have any thoughts on this?

Just a thought on this. It looks like this will result in URLs like: mysite.com/documents/mydocument/ that will directly display a PDF. Correct? Maybe it's just me, but I always like to know when I am about to open up a PDF - it gives me the option to save instead, or open in a new tab, or decide not to open because I am on mobile don't want to wait for a potentially huge PDF file to open. Maybe this is becoming less of an issue now that browsers are directly rendering PDFs themselves, or sites are using mozilla's pdf.js etc. Anyway, just my two cents worth PS, given that you are using a file field, shouldn't: $file= $page->pdf; be: $file= $page->pdf->url;

Ok, I have updated that page with the suggested content. I fixed a few typos, added a git clone section, and also a "How to Upgrade" section. I'd appreciate a look over for any mistakes or possible improvements. Thanks again Richard for putting this together.

Hey Pete, Glad you like it! Do you mean that you have more than one video link embedded on a page? Is that why it is trying to insert more than one thumbnail? Or is it because you are using "All Available", rather than "First Available"? I don't think I actually realized that the the API ignores the max number of images setting. I am happy to fix this, but would like to know if you are dealing with more than one video, or the "All Available" setting. I am also curious what you think would be the preferred behavior - I guess if I replicate the admin behavior, adding a new image would replace the last one, but that seems rather ugly if you have checked "All Available" because it will attempt to add each one, but each time deleting the last one for the latest in the options. Same would go for more than one video link in a scanned field - each image would get added, only to be later replaced. Any thoughts on what the best logic might be here?

Hey Marty, I am not a Formbuilder user so I don't know all the ins and outs, but I just set up a form and tested with CustomUploadNames and the page was created and the filename was changed as it should have been. I have a feeling because CUN and FB both have so many config options, it might be just the combination you have that is causing problems. Perhaps you could export the form for me to test and also take a screenshot of your CUN rule so I can duplicate. I am sure we can get it sorted out for you.

Not sure your exact scenario, but I have made use of: $this->addHookBefore('InputfieldPassword::processInput', $this, 'removeRequired'); public function removeRequired(HookEvent $event) { $event->object->required = false; //hack to remove required status on password field } From memory it's not possible to set the status of the password field directly to not required. I know this is not the same as disabled, but now you should be able to disable or hide it and should work as expected I think. One thing to keep in mind, the system password field is actually named "pass", not "password" like you have there.

I might be missing what you are actually after, but do you know about using something like this for the selector value for a page field: parent=page.otherpagefield That allows for ajax population of one select based on the selected value of the otherpagefield

Replace: $pageid = $this->sanitizer->selectorValue($this->input->get->id); $page = $this->pages->get($pageid); with: $page = $event->arguments[0]; Remember the id get variable won't be available on the front-end via the API. EDIT: Actually, better yet, don't use $page at all, use $p instead - you don't want to overwrite the current $page with the one being saved.

You can click "Edit this Module" and then save it again and it will update version number, readme text etc. You can also wait about 24 hours and it will update automatically.

His avatar is one scary looking Romeo