Hacker News Reader

Comment by maxgashkov | Hacker News Reader

While WP's ecosystem is nothing less than impressive, but I'm still in shock to this day, how cumbersome is site migration.

For me and I guess for many other engineers it's quite normal to develop a site locally (or at least on a staging non-public domain name) and then move it into production under the final name.

In Wordpress, the site name is baked in all over the place — in config, in database, in generated stylesheets and so on. In theory, this should not be like this (if you use barebones install w/o plugins), but then you buy a theme or some less-than-perfect plugin and boom, you need a separate plugin just to handle migration (which may or may not work 100% of the time).

View on HN

> In Wordpress, the site name is baked in all over the place — in config, in database, in generated stylesheets and so on. In theory, this should not be like this (if you use barebones install w/o plugins), but then you buy a theme or some less-than-perfect plugin and boom, you need a separate plugin just to handle migration (which may or may not work 100% of the time).

WP-CLI is your friend:

    wp search-replace 'http://example.test' 'http://example.com'

Don't do that.

Wordpress store some information fields and the length of the string of those fields. Use a plugin that search and replace for those and recalculate the length.

Also, search for //example.test, not http://example.test.

Edit: I read a bit too fast, maybe it does implement the string size but I can't be sure https://github.com/wp-cli/wp-cli/issues/1224

Edit 2: https://github.com/wp-cli/wp-cli/pull/1261 sweet, looks like it does ^^.

As far as I know WP-CLI also handles serialized data correctly.

By the way, I very much prefer the wpmigrate-db plugin.

Also, wpmigrate-db has wp-cli commands to export the database, I don't know if wp-cli search-replace can do that.

Edit: And it does:

    [--export[=<file>]]
    Write transformed data as SQL file instead of saving replacements to the database. If <file> is not supplied, will output to STDOUT.

Well, wpmigrate-db allows to replace multiple strings in one command and that's something wp-cli default search-replace doesn't provide.

Installing a WordPress site is actually very straightforward, in fact the platform is famous for its 5 minutes install. What you are describing as hard to achieve is copying state that is kept in the database, but I don't think this is an inherent issue to WordPress. But if you are creating the entire site locally and want to deploy it to production, it seems that WordPress may jot be the right solution in your case, instead a static site generator would be more appropriate.

That's categorically untrue. Almost all websites are first developed by a developer on his local machine, and then when it's ready to showcase or put online, it will move to the 'real' domain. It is no different for WordPress, and it's true that moving a WordPress site from one domain to another is a bit of a headache.

It should be "gather all things, move it to another place, change the domain name somewhere", but instead it's "gather all things, move it to another place, change all the links, change the domain name in two different places, hope you didn't forget anything or made a mistake somewhere". There are plugins to help you do this though, but all-in-all it's an annoying inconvenience.

Maybe, but I do this on a weekly basis and even with complex custom sites/apps it takes me less than 10 mins to change the urls everywhere throughout the site/database. Decent plugins indeed exist to make this super simple.

I agree the ecosystem is what makes WordPress attractive. I'm impressed by the efforts put into third party themes and plugins that are simply amazing but the WordPress core is a joke.

One of its function name is literally "the_content();" where you output the main content in a theme, no class, no context but just a dumb function that sits globally to force the output and there are global variables like "$wpdb" that keeps the database methods.

Of course, you don't want to look how messy the database schema is. Configuration values are just thrown into the db with serialized strings with random keys, you'll never know what's where.

Seriously a first year high school student would put out a better code and no wonder it took so long to iron out vulnerabilities and performance issues to acceptable levels but the mess is already there and people have to live with it unless someone brilliant creates a new platform with theme and plugin compatibilities to WordPress, so the ecosystem lives for people to move on to it.

actually if you add

  define('RELOCATE',true);

The Wordpress will be in the relocate mode the next time you visit wp-login.php. It will reset all the URLs.

Documentation: https://wordpress.org/support/article/changing-the-site-url/...

Yes, I've read this. Unfortunately that's not enough if you have 3rd party themes or plugins installed.

This just isn’t the case if it’s done well.

If you do need help doing it then migratedbpro or migrateguru are seamless.

It’s, like, really really easy to move Wordpress.

Why would have the site name in a generated stylesheet unless someone wrongly put it there ?

Some commercially available themes do it during installation. I was surprised to find that also as this contradicts every instinct I have as a web developer.

Reply on news.ycombinator.com