Site URLs don't convert

When you say the URLs are not updated, are you referring to what you see in wp-admin or in the database, or what a user would see when accessing the site?

SitePush doesn’t alter URLs in the database, it just replaces URLs when WP outputs the page/post, so it’s only when accessing the site that you would see URL’s being replaced.

If SitePush isn’t fixing the URL’s when viewing the site, can you point me to a page with the wrong URLs so I can take a look?

I have this problem as well. In particular I have copied two production sites over to the new staging sites with a view to making changes/retheming them in staging and then switching to a traditional stage -> production flow.

But when I try and log into the staging servers the login prompt takes me to the production log in. I manually entered the login url on the staging domain but that didn’t work either.

Hi,

I eventually traced my issue to some widgets I was using that were affecting things generally. After I fixed those I the URL conversions worked as expected.

Great plugin generally, would benefit from a bit more setup information related to how the two sites interact with each other and how file permissions really have to be set, but I figured it out.

Thanks.

I had the same problem with permissions – figuring out that rsync needs you to be the owner of the directory so ownersip of root.www-data on files has to be www-data.www-data.

Also the actual permissions you need in Mysql caused me a lot of grief…

Will have a go with looking at the log in page…

OK, I created two vanilla sites:
* one on domain localhost with a file root of /usr/share/wordpress
* one on domain wordpress.dev with a file root or /usr/share/wordpress-master

These are using the 2012 theme.

The fixed site url option is checked

I pushed everything. The following links didn’t rewrite:
* the sitename which should have been a link to localhost/wordpress was to localhost/wordpress-master
* the top navigation home and sample page links were to wordpress.dev/wordpress-master
* leave a reply on the front page comment was to wordpress.dev/wordpress-master
* the categorized tag link was to localhost/wordpress-master
* recent posts links were to wordpress.dev/wordpress-master
* recent comments links were to localhost/wordpress-master
* archives was to localhost/wordpress-master
* categories was to localhost/wordpress-master
* login was to localhost/wordpress-master
* rss was to wordpress.dev/wordpress-master

There is obviously a task to get rid of the /wordpress and /wordpress-master from each of the sites as that will make a **lot** of the issues go away (it is what I do for production sites).

Then I need to figure out how to fix up the widgets, I suppose. Any clues appreciated.

@rampartmanning Glad you got it figured out. If you are able to give me a bit more detail on what was missing from the docs and what you needed to do, I will update them.

@gordon Guthrie thanks for taking the time to look at this. The login page issue will almost certainly be fixed if you define the correct WP_HOME and WP_SITEURL for each version of the site in your wp-config. This should also help a number of the links you mention pointing to the wrong site. For example:-

define('WP_HOME','https://wordpress.dev');
define('WP_SITEURL','https://wordpress.dev');

More info here if you need.

However, in some cases it may not be easy to change the urls. To change a URL SitePush depends on being able to filter the content right before it is output to the browser – it’s possible I have missed some possible filters, or plugins/widgets may bypass the normal WordPress filters. Either way, if there is any particular widget/plugin causing problems with this, let me know and I’ll see if there’s a way to do it.

Ok, made all the /wordpress-master and /wordpress stuff go away – just fixing the URL stuff now…

Any help appreciated…

Mark

I am trying to setup a work flow here and I think I might be misusing SitePush a bit.

The original plan was to push from the current production sites to new dev sites to creaet them.

These would then become pre-production masters and I would always push back from them to the production sites.

I know the theme I am going to be using (or the one that my production systems are going to be based on) should I be looking to ‘fix’ the widgets in that theme (are widgets part of themes?) or ‘fix’ the widgets in all themes?

From the sound of things you are using SitePush exactly as intended ??

Widgets should either be part of WordPress core or plugins, though often themes include widgets in their code (which may cause you problems if you want to change theme).

Either way, it will be case by case if/how SitePush fixes URLs for the widgets. If you can tell me which theme/plugin widgets aren’t working right I can take a look at their code and see if I can fix it.

I have systematically gone through the theme searching the code for href and link and wrapping anything that I think produces a url in esc_url() and a lot of things are fixed, but there are still some major ones.

The recent posts widget doesnt work, nor does most of themeta` widget, but most importantly the actual posts come with headlines and ‘posted by’ linking back to the other site.

I can now login on the site, but it returns me to the master site.

So far I have not added any esc_url()‘s to the core wordpress code – but I can’t see how I can get the RSS stuff to work without doing that. Changing the core wordpress stuff gives me a bad updgrade path, or should I copy their widgets over to the theme (Meta2?) and fix them there?

I’m not sure you have things properly set up yet… recent posts should build correct URLs as required (and so not need any conversion by SitePush), and when you login the fact that you are returned to the master site suggests something’s not right.

Editing WP core code is definitely a bad idea!

Are you sure you have got the WP_HOME and WP_SITEURL constants set correctly for respective sites? One way to check is go to ‘settings/general’ and see what is there for WordPress Address and Site Address. If you have the constants set correctly you won’t be able to edit them, but they should correctly reflect the right URLs for the site you are on.

You’re right – they both had the same url sitename/hostname setup…

Not sure how that happened – I think I created the master and the slave didn’t have an installed database…

Oh well, yip, yip, will get it into production.