jaro

This module (github) does with site/assets/files what Ryan's DatabaseBackups module does with the database: Backup site/assets Download ZIP archive Upload ZIP archive Restore site/assets Motivation: This module can be the missing part for projects with content backup responsibility on the client's side: The client will be able to download DB and assets/files snapshots through the backend without filesystem access, thus backing up all content themselves. Release state alpha – do not use in production environments. Credits for the nice UI go to @ryan – I reused most of it and some other code from the DatabaseBackups module.

Thanks for all of your input on this topic. If we get a 'go' from the customer and our tests succeed, we will likely be using ProDrafts. If that fails and no feasible workaround can be found, we will look into ProcessPagesExportImport again.

Greetings, a current client would like to stage some larger content changes, meaning they want to edit some pages and save them, review those changes, then go live with the changes only when reviews are complete. They want to stage preferably (but not necessarily) in a separate test environment. Some of their templates have repeaters and page tables. I have looked into the following approaches: 2 environments, database dumps: While some large modifications can be staged, most other modifications have to be made in the production system directly, so not an option. 2 environments, site profiles: same as above. 1 environment, ProDrafts: Repeaters seem not to be supported by the module. 1 environment, VersionControl: Doesn't look like it works for repeaters. 1 environment, ProcessPageDraft: Probably works for repeaters (because it copies pages), but is still in beta and would require a large amount of testing. 1 environment, ProcessPagesExportImport (added to the core in 2017): Seems to work fine when used via the GUI. But module info states "Development version, not yet recommended for production use". Is there more information on ProcessPagesExportImport, e.g. is this feature likely to be finalized within a year from now? Does anyone have other ideas? I have not looked into CSV import/export yet. Regards, Michael

Sorry for the even longer delay – as always, the weeks before christmas are the busiest of the year. No worries, I don't feel offended personally, it's just bad PR and that it kind of looks like some careless coding of this module caused data loss. I'd appreciate if you could reword or just remove the link. Thanks for the detailed explanation. I agree, but that's not how I meant it anyway, I was referring to the partial export vs. clean fail design choice. Sticking to the second, I have added a blacklist of known incompatible fieldtypes (containing only repeater so far) for now so the module will not only skip incompatible fields, but refuse to export all fields with a clear error message in that case.

So far, I haven't heard of any case where using this module "breaks an entire system". However, you are claiming that it "nuked [your] system" in your article as well (linking here). I must say I'm really surprised to read about what sounds far worse than the problems mentioned so far by you or anyone else in this thread. Can you please provide some details on what happened there? Thanks.

Fields could be omitted by type, but the output of this module would then not be a complete snapshot of templates and fields any more, which was its purpose in the first place. Do you think, such an incomplete snapshot (without repeater fields and similar) could still be useful for repeater field users? Treating problematic fields differently could solve the problem, but the module would most probably have to be equipped with code for each problematic field type. Yes of course, one or two hints from @ryan could be very helpful now

Thanks guys for all the feedback. I looked into this a little, and I was able to reproduce an instance of the problem using VMO's description with two repeater fields 'rep1' and 'rep2' and two text fields 'text1' and 'text2'. The assignment of text fields to repeater fields got mixed up if and only if the AutoExportTemplatesAndFieldsModule was installed. I could narrow down the problem onto my use of ProcessWire's $field->getExportData() inside a hook 'after' ProcessPageView::finished. The problem is triggered when this function is called on the repeater fields in that hook, so the function seems to have side effects. I have added a minimal showcase for this called 'BreakRepeaterFields module' to the git repository, see module info summary for usage. To sum this up: I am pretty confident there is no bug in my code directly causing the faulty behaviour. On the other hand one could not say that there is a bug in ProcessWire either, as my module is using an internal method which is not part of the documented API. Best I can do for now is to declare this module incompatible with repeater fields and ProFields.

@ICF Church README has been updated. Thanks for your feedback.

Hi, thanks for that bug report, and I'm glad you like that module! I hope I'll have some time to look into this soon. I have added it to the issues on github for now.

Sorry it took me a while to answer, and thanks for the input and for trying it out! The module is all about ProcessWire's built-in import/export functionality, merely exposing and automating it. For the moment I'd rather have it become good and stable in this than doing both formats mediocrely. For example, there are still issues with some common field types, and I want to look into special cases during import that are handled specially by the GUI when doing it graphically. In the meantime I did some tests with ProcessWire versions 2 and 3. The module itself worked without any changes both in v2 and v3 installations (thanks to ProcessWire's namespace magic), but I had to do differentiate in the import script. v1.0.1 contains that and some small fixes.

Thanks, and sorry, I just corrected that statement about your module. Even if it cannot handle all field types that some other modules contribute, I hope I'll be able to improve my module to the point where it reliably warns about field types causing problems.

Thanks, horst Using that version in our project, I have developed and tested for 2.6 only so far. It does not use namespaces, so 3.x will probably not load the module. I will adapt and test with 2.7 and 3.x as soon as my time allows, hope to get to that within the next two weeks too.

Hello, in one of my current projects, we have a test and production stage with their own ProcessWire installations, and we regularly want to migrate template/field configuration to the next stage without migrating content as well. ProcessWire supports this via the import/export functionality in the admin GUI. However we (and some others) would like to do this as part of an automated process. There seem to have been some discussion on this topic and two existing modules that get pretty near our requirements: https://github.com/mindplay-dk/SystemMigrations/blob/master/SystemMigrations.module https://github.com/LostKobrakai/Migrations However, they try to solve more then we need and for mindplay-dk's module, development seems to have discontinued. At that point I decided to build a more simple module with reduced scope that basically just makes ProcessWire's import/export automation-ready. Thanks in advance for trying this out and any feedback! About this Module CAUTION: This module is incompatible with repeater fields and ProFields. The module enables you to transfer template and field configuration from one processwire installation to another in an automated way. Changes to templates or fields are exported to the file system immediately (so they can be added to source control together with changes in the template files) The import script is designed to run from the command line (so it can be invoked from your build/deployment tool). On invocation in import mode, a DB backup is created template/field changes from the persist directory are imported into the DB In restore mode, the import script can restore any of the DB backups previously saved How to Use Make sure the module is installed in the source and destination ProcessWire environments. After installation of the module, you should check if the module's default persistDirectory configuration setting fits your requirements. The module will automatically export all fields, fieldgroups, and templates to JSON files in the directory specified by that setting. Note that the same setting is used by the import script as well, so if you change it, make sure you change it in all affected ProcessWire environments. The JSON files can be transferred to the destination ProcessWire environment. Running the import script from the command line will import template and field data in the destination ProcessWire environment. Manual Installation Caution: Beta software - do not use in a production environment without prior testing and regular back-ups. Caution: This module is incompatible with repeater fields and ProFields. In case automatic installation does not work, get the code at https://github.com/jaromic/pw-autoexport-tf/ and follow the instructions in README.md for manual installation. Manual Uninstall Delete the following files and directories from your module directory: AutoExportTemplatesAndFields/ AutoExportTemplatesAndFields.module Download Install from the module directory, clone the repository via GitHub, or download ZIP.