Data Storage and Working in Teams

Home Page – v1.1 Forums Extensions Layout Manager Data Storage and Working in Teams

This topic contains 3 replies, has 2 voices, and was last updated by  Andy Wilkerson 4 years, 7 months ago.

Viewing 4 posts - 1 through 4 (of 4 total)
  • Author
    Posts
  • #3656

    Eric Sopp
    Participant

    We are working with Runway within a team setup, where each developer is working on their local machine and changes are committed to Github for proper version control. Runway is configured on the shared staging server, but we are struggling with ensuring the same Runway configuration is used across all development environments. Do you have any tips for us?

    We are using the Runway Core, Layout Manager, Sidebars, and Content Types extensions. Of these items, which stores its data in the database vs theme files?

    #3659

    Andy Wilkerson
    Keymaster

    Hey Eric, I’m really sorry for the delay getting back. I’ve been sick ever since my return from PressNomics and dedicating my time to following up on as much as possible in my few functional hours each day. I don’t know if you’ve got kids, but if so I suggest you dunk them in hand sanitizer when they come home from school.

    We’ve done a good bit of development in remote teams and we know that early on there were some things that got weird. We built in additional structures to handle this and ever since that we have not seen a problem. It might be that if you don’t have an understanding of the full data structure it gets confusing. Here’s the basic idea:

    Runway Child themes store all theme specific data (including data types like those added in the Options Builder) and their saved values in the /data folder for the child theme. These are saved as .json files and when you have teams working from multiple locations, adding theme options and setting test data, you need to make sure you are syncing those files. If you don’t do this you could end up with someone overwriting something. When using something like Git that manages the sync through push/pull requests it should work as expected.

    When you create a Standalone theme, upon the first install, all of the saved .json data is migrated to the database. This works in two ways, but here’s the first part. The options created in the Options Builder are stored in the WP database and from that point forward the Standalone theme will only pull the saved values for those fields from the database. If you were to do something like add a new option (to the child theme) and recreate the Standalone theme, that is also handled. That’s the second part. After you do something like make a new option, or remove an old one then generate a new Standalone theme, you can update an existing install and the Runway core will detect these changes. It will update the database options by “syncing” them so you don’t lose any saved values but you keep up to date settings for the theme options to always display the values intended.

    The system is pretty smart in making these determinations. It takes care of the complex data stuff so you can just develop what you need and it will display the proper pieces. This is how we create the data portability so the custom options you develop on the child theme can be transferred to the client install from the very first use. It also makes sure that the data which is local to that WP install is only laved in that location. The potential for this to have very simple import/export features for site migration is also very accessible, but we’ve not needed to build a tool for that quite yet.

    If you notice any mismatches of data, let me know where and what. I’ll see if I can think of how it might be happening. The most important thing if you are using Git is to always make sure you treat the .json files like any other development file and push/pull the changes to your repository.

    #3723

    Eric Sopp
    Participant

    Thanks Andy, this is all helpful information.

    Are the content types also stored in the /data files? We have those within Git, but others are not seeing the ‘Blocks’ content type I created on the shared staging server.

    #3730

    Andy Wilkerson
    Keymaster

    The content types should also be stored in the same place. The individual posts in the custom post type will be local to the current install. I’m not sure why it wouldn’t show up when used this way. It sounds like an issue we would need to investigate specific to that extension. I know they do travel with the theme files.

Viewing 4 posts - 1 through 4 (of 4 total)

You must be logged in to reply to this topic.

Fork us on Github.

Runway on Github

Learn with User Guides.

View the Guides


Thank you for being a part of Runway. We hope you have a great experience and together we can make Runway one of the best additions to the WordPress ecosystem and theme development. We're excited to have you here!

escort kutahya escort bornova escort beylikduzu escort amasya escort diyarbakir
Google+ ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?> ?>