adrian

Sorry about that, I never tested in a multi-language environment. I just took a quick look and committed a fix that seems to be working fine here. Could you please try out the new version and let me know if it works for you.

Either use a Page field or the new Options Fieldtype and then choose the Checkboxes Inputfield. Checkboxes as an Inputfield is very different to the singular "Checkbox" fieldtype.

Thanks for the report @NorbertH! There were a couple of updates this morning: fixing some issues with some page specific settings not overriding the main config settings added support for subfields in the field pairings - verified to work for Profields Textareas and MapMarker fields, but I think should work for most others as well - let me know if you find any that don't work. A question for all you multi-language folks out there - does anyone ever rename the name of the title field? I am sure you often change the label, but the name is what I am concerned about. There are a few places in the module that check for "title" but I am thinking that if this is not always its name, then I might need to check for it by: type = "FieldtypePageTitle" Trouble is that it is possible to have more than one FieldtypePageTitle field on a site which seems a little weird - does anyone know a use case for that? Any thoughts on this?

For those interested, I just committed another small update that includes a couple of fixes from @LostKobrakai as well as support for not needing to define the "title" field in the field pairings if you only have edit and overwrite mode enabled. This should make it much more flexible when running CSV data imports to update existing pages. EDIT: Also just changed "Overwrite" edit mode to be called "Update" to better describe what it does and also to avoid confusion with the "Overwrite Names" option.

I don't think this module currently works with v3 of Google's API: https://processwire.com/talk/topic/784-module-google-calendar-loader/?p=81207 Just a small FYI in case you don't know - those dates are effectively time zero for unix timestamps which is an indication that no datetime is being returned at all.

That would be PageTableExtended https://processwire.com/talk/topic/7459-module-pagetableextended/

Looks awesome - very polished and professional - I can't wait! PS I hope they are a little biased

Ah, right - sorry I wasn't thinking about this style of game - I had no idea they still existed! owzim's comment is much more appropriate than mine

I don't see much use for PW in a project like that unless you have an associated site with profiles of all the players or something, but even so I think in that case I think there are better options for that. I assume the key thing you are looking for PW to do is store info about each player, their score, their weapons arsenal etc? Obviously the game itself will be canvas/javascript. Can I recommend EaselJS for all your game logic and canvas manipulations? I think I would probably go with a completely JS solution and use MongoDB (or some other noSQL DB) for this. There are lots of options.

@mr-fan has already mentioned this, but to clarify, the Field Pairings option is something that is configured on a page by page basis. You set these for the parent page and then all the children that are created from the import follow the defined rules. So I think this allows for the different CSV schemas you are talking about. I thought about doing it per template, but I actually thought that per page was more flexible and natural because afterall this modules is all about creating and the editing child pages of the current parent. I guess this might be a problem if your parent page's template allows for more than one child template. I don't think I have ever allowed this on any of my PW sites, but I am sure some of you do. This module allows the editor to choose the template for new child pages (if the template family settings allow multiple templates or there are no restrictions at all), so if the demand is there, I should be able to implement something along these lines, but please test the current setup first to see if it already suits your needs.

Another new option added to the dev branch! The old "Overwrite" edit mode is now called "Replace" and there is a new Overwrite mode that updates the content of fields of existing pages. An example use case would be to allow editors to periodically upload a CSV file to update certain fields in all child pages while leaving other fields intact. To make this happen you would utilize the Field Pairings option so their import would only edit the specified fields.

Do you have a template file for the page, eg: templatename.php in the templates directory? Edit by Nico: Templates directory is /site/templates/ You can learn more about templates here: https://processwire.com/docs/tutorials/hello-worlds/page2

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?