Jump to content
jaro

AutoExportTemplatesAndFields enables continuous integration of template and field configuration changes

Recommended Posts

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:

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

  1. Make sure the module is installed in the source and destination ProcessWire environments.
  2. 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.
  3. The JSON files can be transferred to the destination ProcessWire environment.
  4. 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.

Edited by jaro
Statement about incompatibility added
  • Like 15

Share this post


Link to post
Share on other sites

Hi and welcome to the forums.

This sounds interesting. I definetly will try it out, but not soon. Maybe in a week or two.

The DB-backup integration looks good. :)

Do you have used it with namespaced PW version 3 too?

Share this post


Link to post
Share on other sites

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.

  • Like 1

Share this post


Link to post
Share on other sites

Now, that's some nice first post to have in the forums, so first of all welcome here.

I just wanted to add a word of caution here. The export functionality should work well for core fieldtypes, but 3rd party fieldtypes might not export/import their settings correctly. Especially for more complex (db-wise) fieldtypes like Table or maybe Matrix it's often not so simple to export to a text format. E.g. FieldtypeOptions didn't export it's options for quite some time. 

Also I'd be cautious with calling modules discontinued, which is, at least for my module, not the truth. Not seeing a weekly changelog is not necessarily a bad thing. 

  • Like 2

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

@jaro @LostKobrakai

<dream mode>

Not sure if this is a good idea or not, but could this module be made to automatically export migrations that are compatible with Benjamin's migrations module? This would allow his module's interface to be used on the importing side to select which migrations to import.

</dream mode>

Edited to add: Now I've actually tried this module, I think the dream outlined above is more of a delusion. As it stands, the module does seem like a very neat way to keep the state of the fields and templates under version control along with the template files; nice work, @jaro!

Share this post


Link to post
Share on other sites
On 3.9.2016 at 1:59 PM, netcarver said:

Not sure if this is a good idea or not, but could this module be made to automatically export migrations that are compatible with Benjamin's migrations module? This would allow his module's interface to be used on the importing side to select which migrations to import.

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.

On 12.7.2016 at 5:01 PM, horst said:

Do you have used it with namespaced PW version 3 too?

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.

  • Like 1

Share this post


Link to post
Share on other sites

Hi,

I Installed the "AutoExportTemplatesAndFields" and when creating repeater fields the module was affecting the fields editing.

I had two repeater fields: "repeater1" and "repeater2", the "repeater1" should repeat the "images1" field and the "repeater2" should repeat the "images2",

the problem was each time I edited one of them and change the repeated field the other assumed that modification. Example: editing the "repeater1" and change the field to "image3" the "repeater2" instead of having the "image2" has the field to be repeated assumed the field "image3".

After uninstall the "AutoExportTemplatesAndFields" module I could edit each repeater and assign different fields to them.

I hope you can find the issue it is a great module to use.

Thank you.

  • Like 3

Share this post


Link to post
Share on other sites
On 1.4.2017 at 5:31 PM, vmo said:

I had two repeater fields [...] the problem was each time I edited one of them and change the repeated field the other assumed that modification. [...] I hope you can find the issue it is a great module to use.

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.

  • Like 1

Share this post


Link to post
Share on other sites
On 4/6/2017 at 2:25 AM, jaro said:

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.

Hi i ran into the same issue und it cost me much time to find the culprit of it. Please at least post a big warning in the readme for users to be aware before installation since i suspect this can affect many users who have installed pro fields

  • Like 1

Share this post


Link to post
Share on other sites
3 hours ago, ICF Church said:

Hi i ran into the same issue und it cost me much time to find the culprit of it. Please at least post a big warning in the readme for users to be aware before installation since i suspect this can affect many users who have installed pro fields

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

  • Like 1

Share this post


Link to post
Share on other sites

This issue hit me a while back too with the RepeaterMatrix field. I ended up posting about it in the Profields support board but, embarrassingly, forgot to let you know about it at the time, jaro. My apologies to all for the oversight.

 

Share this post


Link to post
Share on other sites

The issue, which I'd like to call Agent Smith Bug, that caused a Repeater/RepeaterMatrix field copying itself onto other same type fields while erasing the contents of the fields happened to me inversely without warning. Fortunately, it happened on a site while it's in development. I installed the module way before while browsing for new modules in the directory, and I forgot it was ever installed. It was later I upgraded the core many times, and available modules with the ProcessWireUpgrade module and later I installed the ProFields.

I think we need a special cross-checking notification system, just like a product changes its price or availability in Amazon's shopping cart. One way it was achieved, while you're installing a module it shows a warning for the system version. Right there, a system should notify us with a critical warning that module x would possibly break the behavior of module y. In my case, it would be great if the ProFields installation notified me. But how can it know? (Reminds me the Project Insight scene of Winter Soldier) As humans, we can't check every issue, every board entry.  Hence we need a database, testers, modifiers, structural changes, etc. Too many resources, scratch this idea.

Share this post


Link to post
Share on other sites
On 1.4.2017 at 5:31 PM, vmo said:

I had two repeater fields: "repeater1" and "repeater2", the "repeater1" should repeat the "images1" field and the "repeater2" should repeat the "images2",

the problem was each time I edited one of them and change the repeated field the other assumed that modification. Example: editing the "repeater1" and change the field to "image3" the "repeater2" instead of having the "image2" has the field to be repeated assumed the field "image3".

 

On 2.11.2017 at 1:26 PM, adoxus said:

The issue, which I'd like to call Agent Smith Bug, that caused a Repeater/RepeaterMatrix field copying itself onto other same type fields while erasing the contents of the fields happened to me inversely without warning.

 

On 10.10.2017 at 1:34 PM, netcarver said:

This issue hit me a while back too with the RepeaterMatrix field.

 

On 9.10.2017 at 11:38 AM, ICF Church said:

Hi i ran into the same issue und it cost me much time to find the culprit of it.

 

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.

  • Thanks 1

Share this post


Link to post
Share on other sites

Thanks for looking into it @jaro!

Is there no possibility to check weather a field is / is used inside, a repeater and then treat it differently (or omitting it)? Since this solves a rather critical weakness of Processwire (imho), maybe @ryan can help out with this?

Share this post


Link to post
Share on other sites
7 minutes ago, noelboss said:

Thanks for looking into it @jaro!

Is there no possibility to check weather a field is / is used inside, a repeater and then treat it differently (or omitting it)? Since this solves a rather critical weakness of Processwire (imho), maybe @ryan can help out with this?

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 :)

Share this post


Link to post
Share on other sites

I think a partial export is still better then breaking an entire system ;) So even if it does not do anything, it's still better to if-repeater-return than to do harm imho. You could still log a warning that there have been unsupported fields that need manual exporting so the user knows what fields need to be exported…

Now, as for me, i just had to manually copy a field (not repeater) that I otherwise could have just exported - imported… (which I now did via the db directly)…

Also, shouldn't it be possible to narrow down the problem even further now that we know what causes the problem? What happens if you use "getTableData()" directly?

 

  • Like 1

Share this post


Link to post
Share on other sites
50 minutes ago, noelboss said:

I think a partial export is still better then breaking an entire system ;) So even if it does not do anything, it's still better to if-repeater-return than to do harm imho. You could still log a warning that there have been unsupported fields that need manual exporting so the user knows what fields need to be exported…

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.

Share this post


Link to post
Share on other sites

Hi Jaro, sorry for the long delay.

Now, nuked is probably a strong word, sorry if that offended you, that was not my intention and I can change that.

Now to as what happened: I stored some Configuration (like meta-data, logo, global site info etc) of my site in a Repeater Matrix structure (would rather user functional fields but they don't support all kinds of fields like images etc.) – and I also used several other repeaters on my site. Now whenever I made changes to any of them, the other Repeaters where changed as well, deleting my work I put into creating them and also the data that each of the already existing repeaters held. Thus breaking my site in some cases (where it dependet on configurations beeing present) and losing work, data stored as well as work I put into structuring things.

For example: I created a repeater for Social Media Links and started filling these in. After that I would create another Repeater for Multiple Information Junks. – Now my Configuration Repeater would lose its data, its setup and the same happened with the Social Media Links repeater. I would lose its data plus its setup. I had to recreate the Configuration Repeater and the Social Media Repeater and input the data again.

Until i found the culprit, I lost quite some hours of development work. And it was not obvious from where the problem stemed. At first I thought Repeater was broken, or my setup was wrong (I'm fairly new to PW).

In my humble opinion, dataloss is probably the worst that could happen to a system. A PHP Error, no Problem, remove the module, fix the code. Loss of files – they are under GIT, some work might be lost but not much. But data loss, even more important if it's structural – thats really bad. Things get worse if it's not obvious what causes this data to disappear.

I think, all of this is the case here. Hope this explains it a bit better. If I can be of any help in solving this issue, let me know. BTW, you said

On 11/6/2017 at 10:10 AM, jaro said:

but the output of this module would then not be a complete snapshot of templates and fields any more

with this issue, this is not the case anyway because the module can not handle the repeaters correctly and thus also not export its config corretly, thus the output is not a complete snapshot in the first place ;)

 

Share this post


Link to post
Share on other sites

Sorry for the even longer delay – as always, the weeks before christmas are the busiest of the year.

On 9.11.2017 at 11:09 AM, noelboss said:

Now, nuked is probably a strong word, sorry if that offended you, that was not my intention and I can change that.

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.

On 9.11.2017 at 11:09 AM, noelboss said:

with this issue, this is not the case anyway because the module can not handle the repeaters correctly and thus also not export its config corretly, thus the output is not a complete snapshot in the first place ;)

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.

  • Like 1

Share this post


Link to post
Share on other sites

Hi @jaro

Thanks for the update. Would it be possible to still have a partial export (after checking a confirmation or using module settings)?

I have removed the links :)

  • Like 1

Share this post


Link to post
Share on other sites

Hi @jaro,

I've been having a look at the Repeater issue and the BreakRepeaterFields demonstration.

Interestingly, the issue is not that fields are copied from one repeater to another. It is that the module interferes with the listing of fields when the repeater field settings are viewed in ProcessField, causing the fields of one repeater to appear in the AsmSelect of another repeater. So if you check the database the fields associated with each repeater is actually correct despite the incorrect listing shown in ProcessField. But if the user then saves the field in ProcessField it is at this point that the associated fields become incorrect.

Could you explain why the module needs to hook ProcessPageView::finished? This method fires on every page view, front-end and back-end. But most of these page views will have no connection to field settings or template settings changing. Instead of hooking this method, couldn't you hook only methods that are related to field and template settings? So some method in ProcessField and ProcessTemplate?

And also, the module is looping over all fields on every page view. Could you focus in on just the field that is being edited? So when field1 is edited in ProcessField, just export the data for field1 rather than looping over every field. This would avoid the situation where the data for repeater2 becomes involved when editing repeater1.

I should say that I've just had a brief look at the issue so far, so there might be good reasons why the module does what it does.

  • Like 4
  • Thanks 1

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recently Browsing   0 members

    No registered users viewing this page.

  • Similar Content

    • By gebeer
      I am happy to present my new fieldtype FieldtypeImageFromPage. It is made up of 2 modules:
      Fieldtype Image Reference From Another Page is a Fieldtype that stores a reference to a single image from another page. The image can be selected with the associated Inputfield.
      Inputfield Select Image From Page is an Inputfield to select a single image from images on a predefined page and it's children.
      And there also is a helper module that takes care of cleanup tasks.
      This module evolved out of a discussion about my other Module FieldtypeImagePicker.  It caters for use cases where a set of images is being reused multiple times across a site. With this fieldtype these images can be administered through a chosen page. All images uploaded to that page will be available in the inputfield.
      When to use ?
      Let editors choose an image from a set of images that is being used site-wide. Ideal for images that are being re-used across the site.
      Suited for images that are used on multiple pages throughout the site (e.g. icons).
      Other than the native ProcessWire images field, the images here are not stored per page. Only references to images on another page are stored. This has several advantages:
      one central place to organize images when images change, you only have to update them in one place. All references will be updated, too. (Provided the name of the image that has changed stays the same) Features
      Images can be manipulated like native ProcessWire images (resizing, cropping etc.) Image names are fully searchable through the API Accidental image deletion is prevented. When you want to delete an image from one of the pages that hold your site-wide images, the module searches all pages that use that image. If any page contains a reference to the image you are trying to delete, deletion will be prevented. You will get an error message to help you edit those pages and remove references there before you can finally delete the image. How to install and setup
      Download and install this module like any other modules in ProcessWire Create a page in the page tree that will hold your images. This page's template must have an images field Upload some images to the page you created in step 2 Create a new field. As type choose 'Image Reference From Another Page'. Save the field. In 'Details' Tab of the field choose the page you created in step 2 Click Save button Choose the images field name for the field that holds your images (on page template from step 2) Click Save button again Choose whether you want to include child pages of page from step 2 to supply images Add the field to any template You are now ready to use the field View of the inputfield on the page edit screen:

      View of the field settings

      The module can be installed from this github repo. Some more info in the README there, too.
      In my tests it was fairly stable. After receiving your valued feedback, I will eventually add it to the modules directory.
      My ideas for further improvement:
      - add ajax loading of thumbnails
      Happy to hear your feedback!
       
    • By gebeer
      Although the PW backend is really intuitive, ever so often my clients need some assistance. Be it they are not so tech savvy or they are not working in the backend often.
      For those cases it is nice to make some help videos available to editors. This is what this module does.
      ProcessHelpVideos Module
      A Process module to display help videos for the ProcessWire CMS. It can be used to make help videos (screencasts) available to content editors.
      This module adds a 'Help Videos" section to the ProcessWire backend. The help videos are accessible through an automatically created page in the Admin page tree. You can add your help videos as pages in the page tree. The module adds a hidden page to the page tree that acts as parent page for the help video pages. All necessary fields and templates will be installed automatically. If there are already a CKEditor field and/or a file field for mp4 files installed in the system, the module will use those. Otherwise it will create the necessary fields. Also the necessary templates for the parent help videos page and it's children are created on module install. The module installs a permission process-helpvideos. Every user role that should have access to the help video section, needs this permission. I use the help video approach on quite a few production sites. It is stable so far and well received by site owners/editors. Up until now I installed required fields, templates and pages manually and then added the module. Now I added all this logic to the install method of the module and it should be ready to share.
      The module and further description on how to use it is available on github: https://github.com/gebeer/ProcessHelpVideos
      If you like to give it a try, I am happy to receive your comments/suggestions here.
    • By Robin S
      A module created in response to the topic here:
      Page List Select Multiple Quickly
      Modifies PageListSelectMultiple to allow you to select multiple pages without the tree closing every time you select a page.
      The screencast says it all:

       
      https://github.com/Toutouwai/PageListSelectMultipleQuickly
      https://modules.processwire.com/modules/page-list-select-multiple-quickly/
    • By gebeer
      Hello all,
      sharing my new module FieldtypeImagePicker. It provides a configurable input field for choosing any type of image from a predefined folder.
      The need for it came up because a client had a custom SVG icon set and I wanted the editors to be able to choose an icon in the page editor.
      It can also be used to offer a choice of images that are used site-wide without having to upload them to individual pages.
      There are no image manipulation methods like with the native PW image field.
      Module and full description can be found on github https://github.com/gebeer/FieldtypeImagePicker
      Kudos to @Martijn Geerts. I used his module FieldTypeSelectFile as a base to build upon.
      Here's how the input field looks like in the page editor:

      Hope it can be of use to someone.
      If you like to give it a try, I'm happy to hear your comments or suggestions for improvement. Eventually this will go in the module directory soon, too.
    • By bernhard
      @Sergio asked about the pdf creation process in the showcase thread about my 360° feedback/survey tool and so I went ahead and set my little pdf helper module to public.
      Description from PW Weekly:
       
      Modules Directory: https://modules.processwire.com/modules/rock-pdf/
      Download & Docs: https://github.com/BernhardBaumrock/RockPDF
       
      You can combine it easily with RockReplacer: 
      See also a little showcase of the RockPdf module in this thread:
       
×
×
  • Create New...