Able to access admin dashboard but not able to access site

Do I need to map this name to https://www.universityname.edu/pubweb/nrg anywhere?

I think that this is something you need to discuss with the server’s admin person.

where does the siteurl and home in wp_options table get the name first time after installation?

From the urls that you entered during the installation.

Thanks for the quick reply esmi.

During installation I followed the following steps
1. A folder was created for me on the server to copy my files by admin.
2. A database and user also was created by admin.
3. I copied wordpress files into the folder on the server.
4. I ran the install script where I had to give the database name, database user name, database password, table prefix.
5. Installation was successfull.

I did not give URL anywhere. Where do i provide the URL during installation? Also, the admin page is accessible using the URL
https://www.ndsu.edu/pubweb/nrg/wp-login.php. Why only the site is not working?

I ran the install script where I had to give the database name, database user name, database password, table prefix.

And what url did you use to access the install script?

I used the following URL-
https://www.ndsu.edu/pubweb/nrg/wp-admin/install.php

Thanks,
Shishir

It could be that the server parsed this to point to https://shingle.ndsu.nodak.edu/wp-admin/install.php which is how that url entered the database. As I said initially, I think this is a server configuration issue and you need to speak to your server admin about it. Once you know what url you should be using, we can help you change that in WordPress.

Allright I will check with my admin and let you know the update.

Thanks,
Shishir

My admin says this

https://www.ndsu.edu/pubweb/nrg is set up as a reverse proxy (on spider.ndsu.nodak.edu) to shingle.ndsu.nodak.edu:$SOMEPORT.
Access to $SOMEPORT on shingle is only allowed from spider. WordPress (or one of its plugins) does not know it is behind
a reverse proxy, and is returning shingle.ndsu.nodak.edu in certain URLs instead of https://www.ndsu.edu/pubweb/nrg. This is a problem
you will have to solve within WordPress itself.

Could you please help me with this?
Even if I manually change the URL to
https://www.ndsu.edu/pubweb/nrg in tables wp_options and wp_posts the site does not work. However the admin page works.

Thanks,
Shishir

To be honest, I’m not sure that WordPress is going to work properly within this kind of server set up but I’ll ask around and see if any of your forum regulars have the kind of server experience to help with this.

Would appreciate if you could find some help. Thanks a lot.

-Shishir

No problem. I’ve sent in a ping to ask for server-experienced volunteers to have a look at this for you in the hopes they can come up with a solution

Thanks a lot. Hoping to get this resolved.

Hi Shishir, I am not the expert you were hoping for, but I have a couple things to try if you are willing while you wait for a real expert.

I’m not sure how WP picked up the shingle subdomain, but the fact is it did. The problem now is you have correctly set the home and site urls to the www subdomain, but various links embedded in the content in the database still contain shingle references, which is causing links to fail.

If this is an Apache server, check the .htaccess file in the base folder of the WP installation. It is a hidden file by default, you may need to change a setting in whatever you are using to view files in order to see it. There is typically no references of any urls containing the .edu portion or anything to the left of it. If there is, the directives need to be looked at closely to ensure it is not part of the problem. If there are only relative references (the url portion to the right), all is good here.

Next, make a complete backup of your database. As messed up as it is, there’s slight chance of making it worse. We need to essentially search and replace all shingle references in urls to www references. If all content were simple strings, this would be easy, but some of the urls can be in serialized arrays. If the string content in arrays is changed without updating the length tags, all the data will be corrupted.

There is a utility that can do this correctly for us. It is downloaded from https://interconnectit.com/products/search-and-replace-for-wordpress-databases/. I have not used this utility personally, so I can’t give you much advice other than you need to find all occurrences of shingle.ndsu.nodak.edu in the database and change them to https://www.ndsu.edu/pubweb/nrg .

Once all vestiges of the shingle domain are removed, you should have no more issues. Verify by creating a post and inserting an uploaded image. If it publishes correctly and the image source is from the www subdomain, it is time to celebrate. Good luck.

I was just checking back in and noticed the forum’s parser improperly linkified my search and replace instructions. The replacement text was intended to begin with “www…” and not include the http-colon-double-slash because it was not part of the search text.

Hi bcworkz,

Appreciate your detailed reply. I had already used the search and replace utility to replace all the shingle references to the https://www.ndsu.edu/pubweb/nrg but it did not work. I verified all the tables after replacing and found all the references to be replaced but still does not work. I guess the problem is in the wordpress code files and there should be a fix either in the wp-config file or any other file to handle a reverse proxy server environment.

Thanks,
Shishir

Granted WP may have been confused with the correct URL during the installation, but once installed, it only uses the values in the options table which are apparently now all the www subdomain. If all content in the DB also now have the www subdomain references, then WP has no knowledge of the shingle subdomain anymore.

That leaves only a couple places where shingle references can come from. These must come from the $_SERVER php super global. WP uses $_SERVER[‘SCRIPT_FILENAME’] for several admin functions, which are apparently working. The only other possible source is $_SERVER[‘HTTP_HOST’] which is supposed to be set to the subdomain in the requesting URL. If your server is placing a different value in this variable, WP cannot work properly.

You can test this by pasting the following code into an empty plain text file, save it with a .php extension, then copy it to the base folder of the WP installation.

<?php echo "Server sez its HTTP_HOST is: <pre> $_SERVER['HTTP_HOST']</pre>";

Then request this file in your browser, ensuring you are using the https://www.ndsu.edu variant of the URL. If it returns the host as shingle.ndsu.nodak.edu, WP cannot work correctly. If it returns the host as https://www.ndsu.edu, as it should, we will need to dig deeper.

For a deeper investigation, do a var_dump($_SERVER); and post the resulting source to pastebin.com and post a link to it here. I’ll take a look and see what’s throwing off WP and see if anything can be done about it. You may delete or obfuscate any sensitive information like cookie data, I just need to know all array elements that contain shingle references.