Our company is trying to transition to WordPress Multisite but we have several issues working against us at the moment. We host WP outside our server environment (we use Amazon for our WP sites) so we actually have to use an URL proxy to our Amazon servers. The other issue is that we needed to install Multisite in the root of the folder so the domain is http://100.10.20.30/foldername but we can't proxy that to http://www.domain.com/foldername because that is a live site that we're not moving to WP any time soon. So, of course, the problem we're running in to is that the IP is showing up not only in the source code but in Google now as well (which we don't want).
Does anyone know of anything we can do to keep the IP out of the source code/Google? I was thinking about rewrite rules in the htaccess file but didn't want to do anything until I had some better ideas.
Also, I can't use the domain mapping plugin that everyone seems to suggest for this type of issue because our sites aren't hosted in the root of our server (a prerequisite for the plugin).
So to break it down, this is what we need:
Multisite Parent Blog <-- This has to be the IP address
Multisite child blogs <-- Domain name but when we set the actual proxied domain name in the settings we get a 404 error because it's not looking in the right place. It's looking for an actual folder on our internal servers.
Thanks!
Found the solution myself. Posted below:
In the Multisite dashboard, click on "All Sites" then administer the specific site.
Under the "Path" field, you'll need to deselect the "Update siteurl and home as well."
Save changes.
Click on "Settings" tab.
Change the URL in the following fields: "SiteURL" and "Home"
Save changes.
When all is said and done, the IP is showing in the "Info" tab but it changes the URL in the source code to your domain.
Related
I have a cPanel hosting package, and the staging url is this format: https://cpanelserver.com/~cpaneluserid/.
This does take me to my WordPress site. However, it takes me to the WordPress page "Oh no! No content is appearing for this page!".
Obviously the /~cpaneluserid/ part of the staging url is not recognized by WordPress as a valid page name.
If I try to tack on an interior page name like this: https://cpanelserver.com/~cpaneluserid/about-us/, I still get an "oh no" unrecognized page error.
I don't reach my website if I try removing the the cpanel userid from the url like this: https://cpanelserver.com/ or remove the tilda like this: https://cpanelserver.com/cpaneluserid/.
Has anyone been able to use a staging URL with a WordPress website from cPanel hosting with this same URL format?
UPDATE:
Because my cPanel 'staging URL' has the user-id as a sub-directory, as in
this format: https://cpanelserver.com/~cpaneluserid/, that means
that no one with a WordPress site will be able to use this staging URL format. That is because WordPress interprets the /~cpaneluserid/ as a page name.
And trying to navigate away from this invalid page (page with no content) doesn't work, as this coding: <?php bloginfo( 'url' ); ?> will always return https://cpanelserver.com/~cpaneluserid/, so the new page link will give you this URL: https://cpanelserver.com/~cpaneluserid/newpage/, showing the 'newpage' as a sub-directory of this invalid page '~cpaneluserid'.
Instead, the hosting company should be creating the staging URL with the user-id as a sub-domain, as in this format:
https://cpaneluserid.cpanelserver.com/.
I just heard from my hosting company, and they had this excuse: "Unfortunately we are not providing a staging URL on the cPanel platform due
to the number of potential security risks that are associated with it."
So basically no-one with a WordPress site on a cPanel hosting package can show their clients their website design, to get their approval, before they go live.
I am not sure why the hosting company thinks that this url: https://cpanelserver.com/~cpaneluserid/ is any less risky than this one: https://cpaneluserid.cpanelserver.com/?
So it looks like there is no answer for this post.
But now I am curious how other cPanel hosting companies deal with this 'security risk' of having a valid staging url.. or do they all use the same format as mine?
I finally solved the problem.
It turned out to be a rooky cPanel user mistake!
I had used the cPanel server name for the WP_HOME and WP_SITEURL WordPress settings (ie: https://cpanelserver.com/), instead of the actual location of my hosting package on the cPanel server (ie: https://cpanelserver.com/~cpaneluserid/).
The way I had the settings meant that WordPress ignored the part of the URL that was the defined as the siteurl (ie: https://cpanelserver.com/), and treated everything after that as a page name (ie: /~cpaneluserid/).
So when I used https://cpanelserver.com/~cpaneluserid/. to view the site online, the cPanel hosting package correctly got me to the root of my website location, but WordPress didn’t take me to the home page, instead it took me to the non-existent /~cpaneluserid/. page.
If I had gotten the server name wrong in the WP settings, then I would not have been able to see my site, and would immediately know it was an issue on my side, and would have figured out this issue sooner.
But since I had the server name correct (even though the url was incomplete), I was able to view my site, and know that the database was correct.. so I erroneously thought that my WordPress settings were also correct. Instead, I was thinking that the page presentation & navigation issues where a problem with cPanels temporary URL format.
So in case anyone every has the same problem, I wanted to document it here.
IF you are using your cPanel's staging (or temporary) URL to access
your site before it goes live, then BE SURE TO use the full URL that
points to your cpanel hosting package - which should include your
cPanel user ID as in: ‘https://cpanelserver.com/~cpaneluserid/’ in the
WordPress settings of WP_HOME and WP_SITEURL.
I have created a demo website for a client. I installed the site on the client's live domain name and I used the etc/host DNS trick to point the domain to my development sever. Now I want to send a live preview to client for validation but I don't want to bother her with technical details such as modifying local computer host file. The client doesn’t want to switch the domain to the new site either, until everything is ready as the site is highly active. I have tried the cpanel temporary link (mod_userdir is enabled) but it breaks everything including styles and scripts. Do you have any solution. Thanks.
Update: I have found this site if it can help nodns.io, they only need the emulated domain name and the development server IP.
You can still use the temporary URL and that is the easiest way. You just need to make a change in the WordPress database. You can go to cPanel -> phpMyAdmin, open the database and look for the _options table.
Once you find it, you need to change the home and siteurl options to the temporary URL:
https://codex.wordpress.org/Changing_The_Site_URL
You can follow the "Changing the URL directly in the database" directions.
Goodluck!
I want to set up a multisite network using subdomains under a domain that is used for a non-wp site.
so, for example, we want our domains to look like:
blog1.mysite.com
blog2.mysite.com
but mysite.com points to our main site that is not built with WordPress and is not part of this network.
I'm not sure what to do here since the main domain, site.com in this case, typically points to the root blog on the multisite network.
I suspect this is common and there is a simple solution but I'm not sure where to start.
Update (unresolved) :
I've had a little bit of luck working on this locally but I'm still not out of the water...
my dilemma… I need to set up multisite with subdomains under a domain that is not part of the network? So basically, we have our main site: mainsite.com
and we want to set up a network with subdomains like site1.mainsite.com and site2.mainsite.com.
mainsite.com, however is not a WordPress site and is not part of the network. so If I set the network up under multisite.mainsite.com, then new sites subdomains are created with that as the subdomain like: site1.multisite.mainsite.com
but if I set the current site to mainsite.com, then all of the network admin links break because they point to our main non-wp site.
So, here's what I've done, which kinda works (I'm doing everything locally with my hosts file so I won't know for sure until I get it on a dev box) ...
First I pointed mainsite.com to my local ip in my hosts file and set the network up under mainsite.com
Next I successfully created two sites. multisite.mainsite.com and site1.mainsite.com, through the network admin panel
Then, I changed the 'current site' in wp-config.php from mainsite.com to multisite.mainsite.com and I removed mainsite.com from my hosts file.
Now, I can go to mainsite.com and land on our primary website; I can go to site1.mainsite.com and land on the wordpress site on the network; and I can access the network-admin-section under multisite.mainsite.com
The problem is, since the current site is multisite.mainsite.com, if I try to add a new site to the network, the domain will be site3.multisite.mainsite.com instead of the intended site3.mainsite.com
So I still haven't found the correct solution here but this might help explain my problem a little better
Ok, I figured it out... I didn't realize previously that you can manually change the site url in the site edit screen. Here's a write up with more details: http://georgespake.com/create-a-multisite-network-using-sub-domains-under-an-existing-domain/
In wordpress, how can I change where the links are pointing to without changing the server name or adding redirection?
My main site is a rails app at www.example.com.
I have the wordpress blog on a separate server at blog.example.com/blog
I have a reverse proxy on the primary (rails) server that takes any url that ends in /blog/ and then serves up the blog content. (That's all behind the scenes -- the user never sees the blog.example.com domain)
Currently, I can access the blog via the reverse proxy at www.example.com/blog, but the problem is that the urls on the blog point to blog.example.com/blog (wrong) instead of www.example.com/blog (right).
I've tried changing the urls in wp-config.php, but whenever I change those it breaks something.
I eventually figured it out. Here's what I did.
1) Got rid of the Bitnami wordpress image (on Amazon) and reinstalled wordpress fresh, from scratch, on EC2. Bitnami had a bunch of magic behind the scenes that was making it hard for me to figure out what was going on.
2) Via wordpress admin changed Site Address (URL) from http://blog.example.com/blog to http://www.example.com/blog Previously, I had been changing this in the wp-config.php file, but I am pretty sure that doesn't do the same thing. So I needed to change it in wordpress admin. However I needed to keep the Wordpress Address the same. Found out that the Site Address governs the urls displayed in the theme, whereas the Wordpress Address is the server hostname. I'm using a reverse proxy which is why this was confusing.
3) To enable pretty permalinks behind the reverse proxy I changed the permalink settings in wordpress admin, then I updated .htaccess according to its instructions, then I modified /etc/apache2/sites-enabled/000-default changing AllowOverride None to AllowOverride All. Need to do this to enable mod_rewrite to work on virtual hosts.
Go to wp-admin - settings, and change site url. Than flush permalinks by resaving settings.
You don't really provide a mountain of information. But you will need to check this area of your dashboard
http://www.steveovens.com/wp-content/uploads/2011/09/wpid209-Check__Force_HTTPS_in_site_address__Wordpress_address.png
to make sure the information is
http://54.235.249.193/blog/
In both fields.
If you still have issues try changing your permalink setting to a new setting save it and then change it back again and save.
http://www.webmikesites.com/wp-content/uploads/2013/09/permalink-settings.png
If you are unable to access the dashboard of the site on the address
http://54.235.249.193/blog/wp-login.php
As it redirects you to the other domain.
Then you need to likely change the two fields mentioned earlier siteaddress and wordpressaddress via the database. Find the table in your database wp_options or yourtableprefix_options and edit the fields option_value where the option_name is siteurl and home to have the address
http://54.235.249.193/blog/
Also if you are just starting using a webserver. You may need to make sure your files are writable by the webserver.
I have developed a wordpress based site using xampp 1.8.3. On my local machine all is wordìking fine. On the server I am using php 5.4.12.
On the server I copied the site on a subfolder name site, wich is the same subfolder name I had in xampp/htdocs. Then i changed all occurances of localhost to mydomain.com with the searchreplacedb2.php script (http://interconnectit.com/products/search-and-replace-for-wordpress-databases). I am confident that the tool is working properly and the issue does not depend on it as I have used it several other times with succcess.
Therefore since on my local machine the site was in localhost/site, on the hosting server is on mydomain.com/site.
The proble is that accessing the site home page produces a wordpress managed 404 page with no css being loaded. The title, menu and other site specific text is displayed, therefore the db is being read correctly. Trying to access any page other than the home page gets a webhost managed 404 page. This happens also if I try to access page through non symbolic urls, ei. mydomain.com/site/?page_id=5; therefore it is should not be a redirection issues.
what can be the issue? How can I proceed in troubleshooting it?
Thanks, in advance for your time.
You need to double check everything, first:
Flush the rewrite rules by visiting settings->permalinks then try your pages. Then try:
List item login to phpmyadmin for each domain, check out the database... options table... verify the "siteurl", and "home" columns. make sure they match the respective domains. Then try:
List itemCheck the DNS zone template. Could very well be possible DNS conflicts.