<img> tags when moving db between servers

[mcheck]

Is there a preferred method of managing the urls for images (and other assets) in posts and pages that have a full host and path, when they're moved between servers with, for instance:
cap staging genesis:down:db

When I run the above, my posts/pages all have the absolute staging url in all assets. Is there a workaround for this? Or a way we should be building link and assets references?

[EvanK]

evolution/wordpress#37 has a (currently in-progress) fix for this, filtering the dumped sql file through perl to update urls for the target environment:

https://github.com/evolution/wordpress/blob/35-url-constants/lib/capistrano/tasks/db.rake#L3

Contingent on free time, I might try to backport this into Genesis

[mcheck]

In Genesis, I implemented my own search-replace using awk, but it does not handle serialized values. So it potentially gets to be a mess. Works for the most part though.

In Evolution, I added a cap task that uses wp-cli to change the values. It works great. Wp-cli search-replace handles all the serialization too. Brilliant you guys adding that to the project. My implementation is kinda hacky, because I couldn't figure out how to get the current name of the stage, and future name of the stage, but it's a good start.

[EvanK]

Drat, I hadn't thought about serialized values.

I would definitely prefer to use wp-cli over a perl invocation, but it only supports string replacements (for now: wp-cli/wp-cli#1600)

[mcheck]

It's not as elegant but why wouldn't just string replacements work? My understanding is that we're just changing the stage.domain.tld portion of the urls.

What else is being changed between envs that would require regex?

On May 3, 2015, at 12:17 AM, Evan Kaufman notifications@github.com wrote:

Drat, I hadn't thought about serialized values.

I would definitely prefer to use wp-cli over a perl invocation, but it only supports string replacements (for now: wp-cli/wp-cli#1600)

—
Reply to this email directly or view it on GitHub.

[EvanK]

My concern would be catching branched staging subdomains (custom-branch.staging.example.com), though on second thought the changes in evolution/wordpress#37 should make this a non-issue

[mcheck]

Great! If there is someway I can help, don't hesitate to ask.