adrian

Major feature enhancements currently available on dev branch - https://github.com/adrianbj/BatchChildEditor/tree/dev The new config settings rely on the new "OR" options for inputfield dependencies, so this new version requires the dev branch of PW. Please test carefully and let me know if you have any problems or suggestions! Thanks to ideas, testing and feedback from @mr-fan this module now supports the following new features which mostly focus on enhanced, customized CSV importing for page creation: Custom configurations on a page by page basis (on the Settings tab) - you can set up a default config in the module settings, but override these for any parent page. Ability to set up custom titles, descriptions, and notes so the interface can be tailored to the exact needs of your editors with page/template specific examples. Option to have editing tools in a new tab, rather than in the Children Tab. Alternatively, you can now replace the current Children/Subpages list in the Children tab. CSV upload and link to external URL, in addition to the existing textarea manual / paste entry. Ability to predefine "field pairings". This means that editors can upload/link to CSV files that may contain more fields than you want to import, or there are fields in your template that are not included in the CSV. Think of it as a predefined version of the "Connect the Fields" functionality in Ryan's "Import Pages from CSV Files" module. This makes complex imports foolproof for non-tech site editors. I think in most cases this could now replace the need for custom scripts for editor friendly, regular CSV importing. Despite the added options, it should be just as simple to setup as before if you don't need any of the extra features. Here are some screenshots to give you an idea. Shows a very simple, restricted CSV upload setup with custom title, description, and notes fields. Note that it is in a custom labeled new tab, rather than under the Children tab. All the new parent page specific config settings. Note in particular the "Field Pairings" section where you define CSV column numbers to match PW field names. The only thing I am having some issues with is persistence of some error messages - if you have setup some options that conflict or otherwise cause a specific error to be sent, you may need to save the settings a couple of extra times to make the message go away - not sure if this is a PW bug or what at the moment, but it shouldn't affect functionality.

Do you mean a field from a template? If so, then you should use a page field.

The dev version has an options fieldtype which is perfect for simple selects like this when there is no extra value in using a page field. Have a read about it here: https://processwire.com/blog/posts/new-options-fieldtype-processwire-2.5.17/

Thanks @interrobang, I have just committed an updated that takes care of your request. Now you can enter a mix of module class names for modules in the PW modules directory and URLs to module zip files for any modules only on Github or elsewhere. Should be a great addition.

Ok, module has been renamed to Module Toolkit and can now be considered in beta. In addition to the new functionality noted in the second post, there has been lots of cleanup and one new feature - if you are also running Ryan's ProcessWireUpgrade module, there will be a new button on that module called "Batch Upgrade Modules" that will bring you directly to this module's Upgrade page where you can confirm which modules to upgrade and do them all with one click! I know that there likely is still some needed improvements in error checking and reporting, but otherwise I think all functionality is working well! If you have a chance please test and let me know of any issues you come across.

horst - agreed it will add a complication, but I think a worthy one - otherwise the lazy side of me is going to continue to use the old method, even though some other elements of my modules will likely require PW 2.6 anyways, just because it's easy to copy/paste from existing modules. I think Nico could do a great job of allowing the new option if you check that the module is only compatible with 2.6 anyways. Also Nico, in your validation of fields I think it would be great to enforce camelcase where required. Should be easy enough to compare the entered string to its camelcase version to see if they are the same.

Wicked Nico! I think this could really help us all get a standardized thing going on with our module development, including using strings as version numbers What about an option to make use of the new module config possibilities: http://processwire.com/blog/posts/processwire-core-updates-pull-requests-and-more-2.5.25/#module-configuration-is-now-even-simpler

I think you're looking for the settings here: mysite.com/processwire/module/edit?name=ProcessProfile

I honestly don't know why it is the convention and I don't really like it, but maybe there is a good reason. I am pretty sure you can use strings just fine and I think it would encourage easier use semantic version numbers. One thing to be careful of is things like: 1.1.1 as that won't work as a number, although it should work as a string. 1.1 does work as a number though. At least that is my experience: https://github.com/NicoKnoll/MigratorWordpress/commit/50be6896ffae67dc467a62164fa8cd968462237b EDIT: Maybe using integers just makes it easier to compare version numbers - whether there is a newer version available? Although I am sure we can still do this and have more flexibility. Maybe they should be in three parts, like the PW core: https://github.com/ryancramerdesign/ProcessWire/blob/master/wire/core/ProcessWire.php#L34

10 1 = 0.0.1 10 = 0.1 100 = 1 111 = 1.1.1

Looks really nice soma. Just wondering the reasoning behind the fake scrollbar? It is actually quite hard to drag - testing on Chrome/OSX. You have to get the very left edge of it - any further right and you hit the window resize handle. It reminds me of IE's scrollbar-base-color. For those too young to have ever used this: https://msdn.microsoft.com/en-us/library/ie/ms531155%28v=vs.85%29.aspx

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.