Taking my Local Test Site Live

Well, I spoke a bit too soon. I need to update my internal links. Changing them from https://localhost:8888/wordpresssite/ to https://mind2mind.net/ or https://www.mind2mind.net/ is not the answer. I’ve tried using Velvet Blues but it’s not finding any urls, so I must be malforming them. Man, such a rookie I am!

Changing them from ‘https://localhost:8888/wordpresssite/’ to ‘https://mind2mind.net/’ or ‘https://www.mind2mind.net/’ is not the answer.

First decide which — www or non-www — you want to use, then add a few lines to htaccess to turn one into the other:

https://forum.ait-pro.com/forums/topic/htaccess-redirect-www-to-non-www-htaccess-redirect-non-www-to-www/#post-1723

Go to phpMyAdmin and search all database tables for ‘localhost’ and then browse a bit to see exactly what is there. Using no trailing slashes, next edit your old and new URLs and your table prefix into this code (three places each):

UPDATE pref_options SET option_value = replace(option_value, 'https://www.olddomain.com', 'https://www.newdomain.com') WHERE option_name = 'home' OR option_name = 'siteurl';
UPDATE pref_posts SET guid = replace(guid, 'https://www.olddomain.com', 'https://www.newdomain.com');
UPDATE pref_posts SET post_content = replace(post_content, 'https://www.olddomain.com', 'https://www.newdomain.com');

Select your database and then run that in the SQL box.

Decided on non-www. Found the localhost string. Entered it and the new site into the code you shared. Ran it in the SQL box and was returned this error:

Error
SQL query:

UPDATE pref_options SET option_value = replace(option_value, ‘https://localhost:8888/wordpresssite’, ‘https://mind2mind.net’) WHERE option_name = ‘home’ OR option_name = ‘siteurl’;
MySQL said: Documentation

#1146 – Table ‘buddhain_wordpresssite.pref_options’ doesn’t exist

That, no doubt, is a big clue for you.

b~~~n_w~~~e.pref_options

The ‘pref’ is the placeholder there where your own table prefix needs to be in its place. Also, that b~~~n_w~~~e. part looks to me like possibly a database name and prefix strung together…and I am suspicious of that period being there.

note: Your table prefix is, for example, whatever you see immediately preceding _options after selecting your database and looking at the list of tables.

Wait, stop the presses!

I went back to an earlier post that mentioned htaccess. Inspired by it, I followed the link, copied the repair code, and went to my htaccess page. Hmm, the text wordpresssite was prominent there and not in the WP-supplied code. I copied the existing code and replaced it.

And I seem to have a working website.

God and leejosepho be praised!

the text wordpresssite was prominent there

I would guess it was on the RewriteBase line, yes? That is what you use when WordPress needs to know its installation is a sub-domain.

edit: You might need to search the database for wordpresssite and then re-do the SQL for that URL (no trailing slashes) if it is in there.

I did another search and certainly found many (87) instances of wordpresssite remaining. Many of there were in the guid fields of posts and media files. I replaced several of them, checked to see the effect, and found that my static front page had lost its preferences and that some of my media had come unlinked. I fixed these errors using Dashboard and decided that I was done with links for the time being!

There is still much to fix and much to add to make my website really good, but it’s functioning now and that’s my bottom line. I’m happy that some folks have read my first blog and I think my time will be better spent at this point writing than tweaking the site.

Though I would love to figure out how to cut down on the blank space that appears when the site is viewed on a large screen…

But that’s the sort of thing one might tweak forever and it’s better for me to focus on being what I am (a writer) than what I’m not (a designer).

I did another search and certainly found many (87) instances of wordpresssite remaining. Many of there were in the guid fields of posts and media files. I replaced several of them, checked to see the effect, and found that my static front page had lost its preferences and that some of my media had come unlinked.

In my own experience without knowing much at all about how the WordPress database actually works, making direct, manual edits there has proved to be a bad idea. Overall, it seems it is not as simple as something such as your own experience with a static site where targets are accessed singly and directly rather than dynamically…and I hope I said that in a way that makes some kind of sense! When a browser makes a request, WordPress will go to the database to get what is needed…and that includes discovery of whatever more might be needed (serialized data). So, making a manual change somewhere can break the necessary, required and/or expected flow.

In my own experience without knowing much at all about how the WordPress database actually works, making direct, manual edits there has proved to be a bad idea. Overall, it seems it is not as simple as something such as your own experience with a static site where targets are accessed singly and directly rather than dynamically

Yes, exactly. There’s clearly power in the interrelated, dynamic nature of WP’s code, but it means that everything is so tied into everything else that you can break the whole when you break a mere piece. So, if there are 87 instances of “wordpresssite” in my database and my database is functioning adequately, I am going to leave those 87 instances right where they are, thank you very much!

And, once again thank you very much for mentoring me through this rough intitial experience.