No no no.
I mean the REST of your site. I know, it’s confusing 🙂 Ignore the plugin for a second.
Here’s how I’m envisioning your site:
1) Build the site out at localhost.dev This means I can view it in the browser etc. at the URL http://localhost.dev
2) Run the git push to migrate localhost.dev to my real server, woohoo.com (accessible at http://woohoo.com)
At this point, I’ve changed the home and site URLs from http://localhost.dev to http://woohoo.com however!
WordPress’ internal links (including menus and many site and theme and plugin settings) are all bound to my original domain name in serialized data locations. So I know that in order to properly move a domain, I have to subsequently run a serialization safe search and replace to change any lingering instances http://localhost.dev to http://woohoo.com
Now. If you’re not doing that, it may be why things are weird. Because yes, you should be 🙂
I’m not doing that because when I look at the source code on localhost.dev all of the links are pointing to dream.io NOT localhost.dev. Not just the source code, but the textual version in the editor (I know some plugins change things through some sort of ‘filter’)
Before in installed the plugin they all pointed to localhost.dev and I USED TO have to do a search and replace. Now I don’t have to, however only the links in the post content have the dream.io link the featured images have objects.dream which I CANNOT find in the database anywhere.
No no no no. Not the images!!
I get the images are all dream.io – that’s fine (broken, but for the moment it’s to the side). It’s not my question right now.
I’m asking about the rest of your site.
Menus. Post links to other posts. Site settings.
WordPress hard codes your domain in multiple places 🙂 Forget about images entirely for just a minute. I’m trying to be sure: are you saying you don’t replace any of that?
I get I’m sounding repetitive. I’m not, at all in this moment, asking you about my plugin, it’s settings, or your images. I am literally asking you a generic site-moving-with-domain-change question. And yes, it matters.
Lol, ok sorry.
Menus I’ve pointed to woohoo.com but as far as I’ve been able to determine the siteurl in wp_options controls most of everything else I need to direct on the site. When I have that set as localhost.dev on localhost and woohoo.com on the server, things work out fine.
Okay, so you’re not doing any domain name search/replaces on the main domain… Interesting.
I’m thinking that it’s possible the domain change is somehow subverting the settings and I want to reproduce your process as best I can to try and figure out why it’s being a dink.
In your database (the production one), can you look in the wp_options table for dreamspeed_cdn and tell me what the value is?
Example:
a:7:{s:6:"bucket";s:16:"dreamspeedplugin";s:7:"expires";s:1:"1";s:10:"cloudfront";N;s:13:"object-prefix";s:19:"wp-content/uploads/";s:10:"copy-to-s3";s:1:"1";s:13:"serve-from-s3";s:1:"1";s:9:"fullspeed";s:1:"1";}
They are identical I believe – I changed the actual bucket name but they are the same
I notice it says object-prefix in there, but that could mean that it’s disabled
localhost
a:7:{s:6:"bucket";s:12:"wp-BUCKET";s:7:"expires";s:1:"1";s:10:"cloudfront";N;s:13:"object-prefix";s:19:"wp-content/uploads/";s:10:"copy-to-s3";s:1:"1";s:13:"serve-from-s3";s:1:"1";s:9:"fullspeed";s:1:"1";}
server
a:7:{s:6:"bucket";s:12:"wp-BUCKET";s:7:"expires";s:1:"1";s:10:"cloudfront";N;s:13:"object-prefix";s:19:"wp-content/uploads/";s:10:"copy-to-s3";s:1:"1";s:13:"serve-from-s3";s:1:"1";s:9:"fullspeed";s:1:"1";}
No, object-prefix is right. s:9:"fullspeed";s:1:"1"; is the part I was most interested in. That means when it adds URLs it should parse them as dream.io
This is incredibly weird…
What theme is this?
Sometimes one has to step away from something to figure out why one can’t figure things out.
I took a few minutes to ponder this and came up with a solution by coming at it from the other side.
I changed the “CDN Path Settings” URL to one containing bucket.objects.cdn.dream.io
It seems to work on localhost and remote. So even thought it seems we don’t know why two identical sites are different. They are now the same. I can try to work with you further if you think this is an issue, after all, pretty CDN is pretty.
I’ll keep kicking it, but that is terribly weird…
All I can guess is something in the copylive process isn’t ‘right’ but it all sounds right…
