Jump to content

AutoExportTemplatesAndFields enables continuous integration of template and field configuration changes


jaro

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
Link to comment
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?

Link to comment
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
Link to comment
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
Link to comment
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.

Link to comment
Share on other sites

  • 1 month later...

@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!

Link to comment
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
Link to comment
Share on other sites

  • 6 months later...

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
Link to comment
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
Link to comment
Share on other sites

  • 6 months later...
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
Link to comment
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
Link to comment
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.

 

Link to comment
Share on other sites

  • 4 weeks later...

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.

Link to comment
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
Link to comment
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 :)

Link to comment
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
Link to comment
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.

Link to comment
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 ;)

 

Link to comment
Share on other sites

  • 3 weeks later...

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
Link to comment
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
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Similar Content

    • By MarkE
      This fieldtype and inputfield bundle was built for storing measurement values within a field, rendering them in a variety of formats and converting them to other units or otherwise modifying them via the API.
      The API consists of a number of predefined functions, some of which include...
      render() for rendering the measurement object, valueAs() for converting the value to another unit value, convertTo() for converting the whole measurement object to different units, and add() and subtract() for for modifying the stored value by the value (converted as required) in another measurement. In the admin the inputfield includes a checkbox (which can be optionally disabled) for converting values on page save. For an example if a value was typed in as centimeters, the unit was changed to metres, and the page saved with this checkbox selected, said value would be automatically converted so that e.g. 170 cm becomes 1.7 m.

      A simple length field using Fieldtype Measurement and Inputfield Measurement.
      Combination units (e.g. feet and inches) are also supported.
      Please note that this module is 'proof of concept' at the moment - there are limited units available and quite a lot of code tidying to do. More units will be added shortly.
      See the GitHub at https://github.com/MetaTunes/FieldtypeMeasurement for full details and updates.
    • By tcnet
      File Manager for ProcessWire is a module to manager files and folders from the CMS backend. It supports creating, deleting, renaming, packing, unpacking, uploading, downloading and editing of files and folders. The integrated code editor ACE supports highlighting of all common programming languages.
      https://github.com/techcnet/ProcessFileManager

      Warning
      This module is probably the most powerful module. You might destroy your processwire installation if you don't exactly know what you doing. Be careful and use it at your own risk!
      ACE code editor
      This module uses ACE code editor available from: https://github.com/ajaxorg/ace

      Dragscroll
      This module uses the JavaScript dragscroll available from: http://github.com/asvd/dragscroll. Dragscroll adds the ability to drag the table horizontally with the mouse pointer.
      PHP File Manager
      This module uses a modified version of PHP File Manager available from: https://github.com/alexantr/filemanager
       
    • By tcnet
      This module implements the website live chat service from tawk.to. Actually the module doesn't have to do much. It just need to inserted a few lines of JavaScript just before the closing body tag </body> on each side. However, the module offers additional options to display the widget only on certain pages.
      Create an account
      Visit https://www.tawk.to and create an account. It's free! At some point you will reach a page where you can copy the required JavaScript-code.

      Open the module settings and paste the JavaScript-code into the field as shown below. Click "Submit" and that's all.

      Open the module settings
      The settings for this module are located int the menu Modules=>Configure=>LiveChatTawkTo.

       
    • By tcnet
      Session Viewer is a module for ProcessWire to list session files and display session data. This module is helpful to display the session data of a specific session or to kick out a logged in user by simply delete his session file. After installation the module is available in the Setup menu.

      The following conditions must be met for the module to work properly:
      Session files
      Session data must be stored in session files, which is the default way in ProcessWire. Sessions stored in the database are not supported by this module. The path to the directory where the session files are stored must be declared in the ProcessWire configuration which is by default: site/assets/sessions.
      Serialize handler
      In order to transform session data easier back to a PHP array, the session data is stored serialized. PHP offers a way to declare a custom serialize handler. This module supports only the default serialize handlers: php, php_binary and php_serialize. WDDX was dropped in PHP 7.4.0 and is therefore not supported by this module as well as any other custom serialize handler. Which serialize handler is actually used you can find out in the module configuration which is available under Modules=>Configure=>SessionViewer.

      Session data
      The session data can be displayed in two different ways. PHP's default output for arrays print_r() or by default for this module nice_r() offered on github: https://github.com/uuf6429/nice_r. There is a setting in the module configuration if someone prefers print_r(). Apart from the better handling and overview of the folded session data the output of nice_r() looks indeed nicer.

      Links
      ProcessWire module directory
      github.com
    • By Robin S
      Repeater Easy Sort
      Adds a compact "easy-sort" mode to Repeater and Repeater Matrix, making those fields easier to sort when there are a large number of items.
      The module also enhances Repeater Matrix by allowing a colour to be set for each matrix type. This colour is used in the item headers and in the "add new" links, to help visually distinguish different matrix types in the inputfield.
      Screencasts
      A Repeater field

      A Repeater Matrix field with custom header colours

      Easy-sort mode
      Each Repeater/Matrix item gets an double-arrow icon in the item header. Click this icon to enter easy-sort mode.
      While in easy-sort mode:
      The items will reduce in width so that more items can be shown on the screen at once. The minimum width is configurable in the field settings. Any items that were in an open state are collapsed, but when you exit easy-sort mode the previously open items will be reopened. You can drag an item left/right/up/down to sort it within the items. The item that you clicked the icon for is shown with a black background. This makes it easier to find the item you want to move in easy-sort mode. You can click an item header to open the item. An "Exit easy-sort mode" button appears at the bottom of the inputfield. Configuration
      In the field settings for Repeater and Repeater Matrix fields you can define a minimum width in pixels for items in easy-sort mode. While in easy-sort mode the items will be sized to neatly fill the available width on any screen size but will never be narrower than the width you set here.
      In the field settings for Repeater Matrix you can define a custom header colour for each matrix type using an HTML "color" type input. The default colour for this type of input is black, so when black is selected in the input it means that no custom colour will be applied to the header.
      Exclusions
      The easy-sort mode is only possible on Repeater/Matrix fields that do not use the "item depth" option.
       
      https://github.com/Toutouwai/RepeaterEasySort
      https://processwire.com/modules/repeater-easy-sort/
×
×
  • Create New...