[wp-hackers] Two new, long-overdue plugins to make your wordpress life a little easier...

Tue Nov 1 00:27:31 UTC 2011

So to be clear, Marcus, all this and you're not even using WordPress to generate content on the production server? Why *don't* you use a more CMS-centric solution like Joomla! or Drupal?

You're ignoring WordPress's own publication workflow and instead using separate databases to create a workflow. WordPress is, at its *core*, a blogging platform. If you're blogs require three databases to properly workflow, I don't think a blog is what you're actually looking for.

That said, I do enterprise-grade WordPress sites for a living, including sites that may not be readily consider a "blog." I love WordPress, and have had no significant challenges in my workflow. But once the site is live, new content is created on the production server and published when it's approved. Why on earth would I need two or three databases (or at least schemas) to create content workflow when it's built right into the platform? (BTW, I also have clients that require WCGA 2 AA compliance, and it's not a problem. )

-----Original Message-----
From: wp-hackers-bounces at lists.automattic.com [mailto:wp-hackers-bounces at lists.automattic.com] On Behalf Of Marcus Pope
Sent: Monday, October 31, 2011 4:43 PM
To: wp-hackers at lists.automattic.com
Subject: Re: [wp-hackers] Two new, long-overdue plugins to make your wordpress life a little easier...

Dagan, if you create three hosting environments (dev,staging,prod) and point them all at the same database, you'd have that problem with relative or absolute urls.

One intention with relative urls is to preclude the necessity of doing search/replace operations on the database content or using a tool to do it natively in wordpress environment.  So if you push content from dev to staging to production, you won't need to alter the database content at all.

One caveat of this process, is that you can't/shouldn't push the entire database to production if production already exists.  This is again a problem regardless of the url format.  You wouldn't want to overwrite/delete newly generated comments in production with a full copy of the staging database.  That is typically overcome by only exporting key tables that do not apply to user submitted content (in this case, typically comments.)

People handle this aspect differently, but the premise of having the dev/staging/production environments to begin with is that you never use the production wp-admin interface at all for content generation or alteration.  As a process you would generate it in dev, send it to qa, and only after confirmation of quality and customer sign-off, would you push it to production.  And each environment should have its own database to prevent cross-contamination.  QA departments would be mighty upset if their automation tests broke because you added or removed content in the midst of a test because it violates the sanctity of testing in isolation.

There are tactics to handle two-way syncs, so that during an outage period, you would sync the database down entirely from production to dev, then apply via a sql patch the records you wish to add to/remove from the database from the staging.  Send the merge through a final smokescreen round of QA and then push the result back to production.  After the entire process is complete you then open the site back up to end-user access.  Many websites go this route and the result is a much larger maintenance window/downtime.  But sometimes it's a requirement because the distinction between user submitted content and site generated content may not be so clear as it is with a vanilla wordpress install.

But the relative url theory doesn't just apply to removing the search-replace step, it also applies to accessing your host in a variety of ways - like using http://127.0.0.1/ or localhost on your dev workstation and using http://mycomputername/ on your iphone to test your development work from both a browser on your computer and your iphone over your wifi network.

-----Original Message-----
From: wp-hackers-bounces at lists.automattic.com [mailto:wp-hackers-bounces at lists.automattic.com] On Behalf Of Dagan Henderson
Sent: Monday, October 31, 2011 5:40 PM
To: wp-hackers at lists.automattic.com
Subject: Re: [wp-hackers] Two new, long-overdue plugins to make your wordpress life a little easier...

I'm still wondering how relative URLs solve the underlying problem here. If you create the perception of totally segregated environments (dev, staging & production), but in reality, all three environments rely on the same WP tables, don't you create a content-developer's nightmare where publishing content to "staging" _actually_ publishes it to production as well? 

-----Original Message-----
From: wp-hackers-bounces at lists.automattic.com [mailto:wp-hackers-bounces at lists.automattic.com] On Behalf Of Robert Lusby
Sent: Monday, October 31, 2011 1:10 PM
To: wp-hackers at lists.automattic.com
Subject: Re: [wp-hackers] Two new, long-overdue plugins to make your wordpress life a little easier...

On 31/10/2011 20:01, Aaron Jorbin wrote:
> On Mon, Oct 31, 2011 at 3:56 PM, Robert Lusby<nanogwp at gmail.com>  wrote:
>> They want to see the 100% finished article. With container, content, 
>> and
>> *everything* in place, "before" going live.
>>
> Perhaps we should add a button in the write panel labeled 'Preview' 
> just for this purpose?  oh. wait.
>

Perhaps we should read the rest of the email first.  ; - )

Last I heard, preview doesn't pull in template / file changes without putting them live first? Doesn't solve the problem mentioned in my email.

R

_______________________________________________
wp-hackers mailing list
wp-hackers at lists.automattic.com
http://lists.automattic.com/mailman/listinfo/wp-hackers
_______________________________________________
wp-hackers mailing list
wp-hackers at lists.automattic.com
http://lists.automattic.com/mailman/listinfo/wp-hackers
_______________________________________________
wp-hackers mailing list
wp-hackers at lists.automattic.com
http://lists.automattic.com/mailman/listinfo/wp-hackers