0

Basically: I want my work to be meaningful and efficient. I am considering making my local development AND staging database the same thing.

I would develop on my local machine but have the SQL data stored on a web server.

I could build the site and move the important parts to staging where I can give the client access for writing text when they want to supply their own copy. I could keep building other features and pages while the client edits the contents on the staging and the database stays up to date for both parties.

I then sync project files (not database) from local to git + staging and client sees new pages up for text editing.

Is this viable? Are there shortcomings I'm not foreseeing? Has anyone done this?

If this is not how your agency does things, what's your way of development?

Improve this question

2 Answers 2

Reset to default
0

Wordpress, and many of its plugins, store configuration data in the database. That alone could cause issues for the setup you described, but the urls of every link will also be stored fully canonicalized. So, unless you plan to test your staging setup from "http://localhost", you will have serious issues trying to click around multiple resources for testing.

It is far better to setup separate databases, and not just because of the difficulties I have outlined. Having completely separate environments frequently exposes flaws in programmers' assumptions. The more often you distribute and re-test software, the more flaws appear before they reach your production environment.

If you want the same exact content in both places, I recommend you write an automation script or two, to perform the migration as quickly as possible.

In any case, I would very strongly recommend against pursuing the environment you described.

Improve this answer
0

this is actually the same method I follow when I'm about 60-80% complete with the total theme build. it allows my client (or my co-workers) to work on the content and update the pages and thus the database on the staging server while I continue working locally on other custom page development, templates, etc.

the only downside I've experienced is that it basically restricts you to theme coding-only during this timeframe since any database modifications you make locally will start to get difficult to track against the more active database on staging ... and if you aren't clear with communications or tracking progress, changes, etc. it can get messy real quick and content updates can get lost if you didn't know your local database was actually behind the staging db, etc.

probably works best for smaller teams, and strict compartmentalization of tasks you are assigning to other people!

Improve this answer
4
  • Are you actually using your local server to access your changes and updates, or just modifying the code on local and verifying the changes on staging? If you're able to view everything on local, I'd be REALLY interested to know how you address the variations in parameters like the home_url, etc...? I have found overcoming that to cause multiple inconsistencies which ended up affecting the production deployment after tons of testing failed to detect issues, specifically because testing the local instance with a shared database hides defects on local with staging content and settings.
    – Mike Baxter
    Commented Sep 24, 2019 at 20:59
  • it's pretty simple, I'm coding AND reviewing locally via MAMP application. I'm making using of codex.wordpress.org/Function_Reference/… throughout the theme files to maintain that relative path for all inline file locations and then the only thing I need to change when updating the staging db is the 2 fields (home_url and site_url) in the wp_options table in the database
    – mrtoast
    Commented Sep 25, 2019 at 14:49
  • Sorry to sound so skeptical, but this clearly means that you cannot have clients working on the Staging server, (adding content that you would see, use, and/or add to) from your local. This could not take place at the same time, as the question was asked, because (as you have noted) the home_url and site_url must be changed on the Staging server, or it will not work. Ultimately, it is your call @Jussi, but I prefer the more pragmatic approach of maintaining separate databases. It provides far more assurances that you won't miss something important.
    – Mike Baxter
    Commented Sep 25, 2019 at 16:48
  • To be clear, I am treating the staging server as the master branch. When I allow the client to work on the content/database on staging, I then limit my local work to strictly theme files-only knowing the staging db will soon be ahead of my local one. I find it more practical to maintain only 1 database accepting the temporary pause on local db work and the small amount of overhead it takes to change the site_url and home_url between pushing/pulling between staging/local so I can still review a version of the website locally without disturbing the staging theme files where the client is working
    – mrtoast
    Commented Sep 26, 2019 at 18:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.