Formidable Forms Community Site

The Community forums are being phased out in favor of a new Slack group.
Add your email address below to get an invitation to join the community slack group

Slack Signup
Newsletter Optin
Help Desk
Subscribe

Source control strategies for Formidable (VersionPress)

Labels

This Discussion is public

Notifications

I use Formidable Forms for rapid application development of enterprise applications. I typically have 100 forms and views in an application. I back up my WordPress instances nightly using Duplicator Pro and so far I have "got away with it". This was until yesterday when I have found a plugin conflict that arose at sometime in the past and I have few diagnostic tools available.

So now I am looking at how to best to implement version control with WordPress and Formidable.

  • One solution is VersionPress - has anyone used this? Does it work well with Formidable?

Do you have a preferred method of source controlling your theme and plugin  files? If so please

  • Explain or link to your methodology

What is your preferred way of deploying from your Development to your Live environment?

  • Normally
  • When key functionality is in Formidable Forms

Thank you for reading this. I will return to this thread and update it with my learnings over the next few months.

James

 

You really don't need multiple workflows. VersionPress is a shell for Git. Git is my goto tool for version control. The benefit of VersionPress is that it versions the database as well as source code. Unless you are writing custom PHP to use with Formidable Hooks, every other change you make is stored in the database, so you want the database versioned with Formidable.

VersionPress may not work on shared hosts. It relies on the proc_open command that is disabled in most shared hosting environments. Also, because of the huge number of plugins in the wild, VersionPress may not work for specific plugins on a site. In that case, you have to go through the laborious task of writing your own plugin definitions.

This is very helpful Vfontjr,

I now understand that VersionPress is an excellent solution because

Formidable Forms are stored in the database.
Applications screens (forms, views, and posts) are stored in the database

Therefore my primary need is for a tool that versions the database and VersionPress does this.

The VersionPress documentation says that it should not be run on production systems. My assumption is that I should run it on my development system and have automatic updates turned-off on production.

Is this how you work?
How do you deploy changes from development to production?

Many thanks,

James

 

Attachment:

Turning off automatic updates in production depends on your host. If you are on a managed WordPress environment such as WPEngine or a shared host like SiteGround, you won't be able to turn off automatic updates. You may be able to delay some updates like the V.5.x, but eventually the host will re-enable them.

When migrating from dev to production, in most cases, moving themes, plugins, media, etc. can be handled by a plugin like Updraft Plus or one of the other migration tools.

The problem is with the database. You can't just overwrite a production database with changes from development. If you do, you'll lose all production data from the last time the two instances were synchronized. This might not be a problem for minimal content systems. It will be a problem for eCommerce and web applications where data is updated regularly.

With Formidable, you have to export from development and import into production. This means that any custom code, views, etc, should reference field keys rather than field ID. Field IDs are generated by WordPress and will change as you import/export to other instances. Field keys remain static across all instances.

Always make a backup of production before you do any kind of updating. This way you can restore to the status quo if things go south.

Thank you for your great advice. I note that I have have hundreds of references to Field Ids that I will have to change to Field Keys. I will build on what you have suggested and update this thread.

James

 

Discussion closed.