On a Windows 2003 server running IIS 6.0 and FastCGI with an ExpressionEngine-powered website, I've encountered an issue where links containing index.php fail unless a question mark is added.
The basic issue is that if a link points to "index.php/archive/article", the page fails to load (see below) but it will work when "index.php?/archive/article" is used.
What happens when the "index.php" links fail is the URL will change in the browser address bar, but the main page content is still displayed. Append a question mark to "index.php" and the page loads properly.
The site was previously running with ISAPI as the Server API with no issues: the server saw "index.php" and "index.php?" as being synonymous and pages with "index.php" in the path would load as expected.
How would I configure setting somewhere which would tell FastCGI to treat "index.php" and "index.php?" the same way?
I am a bit green when it comes to Windows servers; my experience is mostly with Apache servers running on Unix boxes.
Any guidance or pointers would be most appreciated.
One option is that you could simply enable EE's force URL query string option.
But, if you don't like having the question mark in the URL, you can try this workaround.
I can't say that I know anything about Windows servers, but this has worked for me on Apache servers when running PHP as CGI. Best of luck!
Related
Context:
I've recently moved a site to a new host, and moved the SSL certificate from the old host to the new one. The code, written in PHP, is a big mess made by someone no longer available many years ago. Because of this, I'm hoping to figure out something related to the configuration of the server that can fix the issue so I don't have to reverse-engineer the rather messy code.
Problem:
When users navigate to an area of the site that uses https://, all goes according to plan. The problem, however, arises when they click a link in the navigation that is normally to an http:// part of the site. On hover, you can see that the target URL incorrectly includes "https://". When the user tries to go to a non-secure area with https:// in front, either by clicking one of those altered links or by typing it into the location bar of the browser, they are redirected to the directory without any domain. For example, if you try to go to "https://domain.org/site/", the browser is redirected to only "/site", which of course cannot be found.
Theoretical solutions:
Is there a setting in Plesk which governs the "stickiness" of https? One way to fix the problem is to stop the non-secure links from acquiring https://.
Is there an obvious reason why whatever script or file the site is using to redirect would break when an un-secure area is accessed via https://? Is there a server setting that would have made this function differently on the new server via the old server?
I don't have access to see what exactly the configuration of the old server was. Is it likely that this could be caused by a difference in PHP version? If so, any suspicions about what the problem would be?
Is there some workaround with .htaccess that can manually redirect all but certain secure areas of the site to http:// when they are accessed via https://, presumably before the site's redirect script is activated?
Thank you for any help!!
Yes, since Plesk 17 (Onyx):
For older versions you can create .htaccess files which will rewrite request from https pages to http, based on referrer:
RewriteEngine on
RewriteCond %{HTTP_REFERER} ^https://domain.org [NC]
RewriteRule ^(.*)$ http://domain.org/$1 [L,R=301]
I'm just starting to learn web dev, but got myself a bit confused when setting up my local development environment.
I had a php site on shared hosting for some time. I would edit local files and upload them, then refresh to ensure everything worked. A naughty practice I know!
So I have tried to set up a local dev environment and installed AMPPS for a local webserver (PHP5).
I have ambitiously set up the folder structure below so that I can code up a range of websites to try out different languages and frameworks whilst keeping them all seperate. (Square brackets denote folders). Note sure if this is the correct approach... (?)
-->[PHP]
---> [AMPPS]
----> [www]
-----> [PROJECTS]
------> [project_name]
-------> index.php
-------> .htaccess
-------> [images]
-------> [section1]
--------> page1.php
-------> [etc...]
------> [project_name]
------> [project_name]
--> [RUBY]
--> [PYTHON]
My first hurdle however is that all of my links were relative, and I had of course uploaded my site at root with my host. Root in my local dev enironment is now www, which as you can see is several folders up from where I have installed my site.
Links (e.g. Page 1) now display as: "localhost/section1/page1.php" when I believe they should in fact show as "localhost/PROJECTS/project_name/section1/page1.php".
I don't think that telling APACHE that my root directory is [project_name] is the correct approach, because then it wont work for other projects I create. I assume that I should be doing something on a project by project basis to specify it's own root directory.
I thought that I could specify root by adding an .htaccess file to the project_name folder:
From my online research I thought it would go something like:
RewriteEngine on
RewriteRule ^/$ /PROJECTS/project_name/
or perhaps
RewriteEngine on
RewriteRule ^/$ .;C/PHP/AMPSS/www/PROJECTS/project_name/
However I can't get these to work.
When the site was online, I had also coded <?php set_include_path($_SERVER['DOCUMENT_ROOT']); //Look for includes starting from ROOT location ?> at the top every page, thinking I was doing the right thing.
Now I am not so sure that I correctly understood what I was doing there. It doesn't seem to have any impact with or without it in my development environment. And I haven't been able to edit it in any way successfully to resolve my relative links issue.
Sorry for the long post.
I'm grateful for any and all feedback/assistance. Thanks in advance :)
[Resolved] - The advice below was perfect. Thank you all. :)
A tip for Chrome users:
If you are using a custom domain, like I did with .dev, either proceed the address with http://, or end it with a trailing /.
For example I now visit my dev site in Chrome by visiting projectname.dev/ (without the last / it tries to search).
At first I thought I had set up VirtualHost or hosts incorrectly, when in reality it was this Chrome behaviour that that was clouding the issue. At the time of writing, other browsers like Firefox don't share this concern.
Hope that helps someone else out.
You're correct that configuring Apache for each project is the way forward. It's best done with virtual hosts. Define a virtual host for each project and give it a domain name or subdomain for development. In my case I use test.com for all my local development and configure project1.test.com, project2.test.com etc so all my relative paths work as expected. For this I also edit my hosts file so the DNS lookup for test.com and sub projects resolve to my local machine.
Rewriting URLs is something I reserve for a project-by-project basis, without setting global rewrites for a specific server setup. That way my local development environment is close to the actual server environment and project-specific rewrites will work as expected.
Hope that helps
I recommend using method mentioned by #Tak, but I know there might be problems with pre-configured WAMP packs to add virtual hosts, so there is also a solution to use BASE tag in head section of your html:
<base href="http://localhost/PROJECTS/project_name/">
How do I configure Apache to prevent my users from explicitly surfing to http://myurl/somepath/index.php
' Having index.php attached to the end of the URL looks ugly, to say the least.
Have you tried URL Rewriting? I am not a PHP dev, however I do know that at least in ASP.NET you can setup URL Rewriting at the server level, as well as code level (on individual pages).
I've encountered a problem when moving a Wordpress installation from a Linux Apache server to a Windows IIS server. Nearly all pages load blank, including /wp-admin/. I created a php file in the main directory to check phpinfo, and it loads fine.
I've copied the file system over, as well as the database. I've also updated the wp-config.php with the correct credentials.
I think it has something to do with .htaccess, but I'm not sure how to correct it. Any help would be greatly appreciated.
.htaccess is not used on Windows IIS servers.
http://learn.iis.net/page.aspx/557/translate-htaccess-content-to-iis-webconfig/
Sounds like you have a permalink problem, compounded by the fact that permalinks operate differently on IIS than Linux. See: Using Permalinks « WordPress Codex
Try resetting permalinks to default in Dashbord/Settings/Permalinks, if you can get into Admin. If not, you need to go into the database with phpmyadminand manually clear the permalink field in wp_options, usually around option 34.
Update: And, did you change domains? Or just hosting? See this, too: Moving WordPress « WordPress Codex
We are putting up a company blog at companyname.com/blog but for now the blog is a Wordpress installation that lives on a different server (blog.companyname.com).
The intention is to have the blog and web site both on the same server in a month or two, but that leaves a problem in the interim.
At the moment I am using mod_rewrite to do the following:
http://companyname.com/blog/article-name redirects to http://blog.companyname.com/article-name
Can I somehow keep the address bar displaying companyname.com/blog even though the content is coming from the latter blog.companyname.com?
I can see how to do this if it is on the same server and vhost, but not across a different server?
Thanks
Rather than using mod_rewrite, you could use mod_proxy to set up a reverse proxy on companyname.com, so that requests to http://companyname.com/blog/article-name are proxied (rather than redirected) to http://blog.companyname.com/article-name.
Here are more instructions and examples.
There is functionality with ZoneEdit called webforwards which could probably do this and hide what you are actually doing (unless someone looked into it).
The only thing that mod_rewrite can do is send HTTP header redirects, and those redirects (across servers) always result in the browser address bar reflecting the reality.
You should instead consider writing a 404 script that 'reflects' the blog. This would essentially be a transparent proxy, and many are already written.
The script would find if the requested page (that was 404'd) started with http://mycompany.com/blog/ . If it did, it would download and then send onto the client the blog page and associated files (probably caching them as well).
So requesting http://mycompany.com/blog/article_xyz would cause the 404 script to download and send http://blog.companyname.com/article_xyz.
It's probably more work than it's worth, but you might be able to design a simple enough 404 script that it's worthwhile.
-Adam