1

I don't know if this is a new thing or if it's been an issue all along, but the client just noticed and i recreated the issue myself. If I clear my browser cache and then visit my client's site at a URL like http://www.example.com/product/product1 it will redirect to http://www.example.com/index.php/product/product1. The page looks fine. After refreshing or visiting that URL again the URL will pull up correctly at http://www.example.com/product/product1. If I clear my browser cache again it will redirect to the index.php url again.

Here's my .htaccess file, any ideas why this might be happening? Thanks for any ideas!

RewriteEngine On

RewriteCond %{HTTP_HOST} !^www\.
RewriteRule ^(.*)$ http://www.%{HTTP_HOST}/$1 [R=301,L]

RewriteCond $1 !(^index\.php|(\.(gif|jpe?g|png|css|js)))$
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ /index.php/$1 [L]

Redirect 301 /helpdesk http://helpdesk.example.com
Redirect 301 /splash http://example.com
Redirect 301 /webmail http://mail.example.com:32000
Redirect 301 /email http://mail.example.com:32000
Redirect 301 /timeclock http://timeclock.example.com:62345
Redirect 301 /signature http://signature.example.com

EDIT: I modified my .htaccess file to the recommended one from EllisLab and that seems to have fixed the index.php from showing up. Something is still a little wonky though. When I clear the browser cache and visit a url with a hash tag at the end (http://www.example.com/product/product1#tab3), the redirect removes the hash tag and the rest of the url after it. If I refresh the page it will work as expected. it only has issues with the first time visiting the url after a clean browser cache. Any ideas?

    RewriteEngine On
    RewriteBase /

    # Removes index.php from ExpressionEngine URLs
    RewriteCond %{THE_REQUEST} ^GET.*index\.php [NC]
    RewriteCond %{REQUEST_URI} !/system/.* [NC]
    RewriteRule (.*?)index\.php/*(.*) /$1$2 [R=301,NE,L]

    # Directs all EE web requests through the site index file
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteRule ^(.*)$ /index.php/$1 [L]
6
  • This seems like an environment thing... on a LAMP stack Digital Ocean spun up machine running EE 2.9.2, your original .htaccess script dropped-in, in place of what I had already there, and all paths worked exactly the same from different browsers and IP addresses without your issue. Please explain your hosting solution for this issue? – jrothafer Mar 30 '15 at 5:29
  • I'm using ArcusTech VPS for hosting. I contacted them and they looked into it, but said they don't support .htaccess support – Mike Lohrman Mar 30 '15 at 22:06
  • Ah. I (my employer) uses Arcustech and Digital Ocean (for dev testing spin ups) and have never notied a problem with Arcustech servers and any weird caching. BTW, I would bet money that this related to a caching issue between source and host, and very likely your local machine. – jrothafer Mar 31 '15 at 2:45
  • Unfortunately my client is the one that noticed it first, so it is happening other places besides my local machine. Here's an actual link to the site...synergeticsusa.com/products/featured/… Would you mind trying it out and seeing what happens on your computer? it should load with the hash still at the end of the URL and that should make the "Tip Configurations" tab active down the page. – Mike Lohrman Mar 31 '15 at 14:17
  • Try adding a query string append to these lines (the QSA part): RewriteRule (.*?)index\.php/*(.*) /$1$2 [R=301,NE,L,QSA] RewriteRule ^(.*)$ /index.php/$1 [L,QSA] – jrothafer Mar 31 '15 at 14:31
2
+100

On further investigation, it appears that this redirect is coming from inside that template.

See the attached image

enter image description here

All of your header assets are being loaded just fine until something else triggers the redirect, in this example it happened after the server already responded to 15 gets from the generated page. What kind of addons does this template use? Try investigating that.

EDIT: To be clear, anchor tags are never even sent to the server. If it is the .htaccess setup, there is no way it's rewriting anything based on anchors.

6
  • I think you got it. I had installed the MX Mobile Detect plugin for some reason in the past. I disabled the tag in the head and it looks like things are working fine again. Can you clear your browser cache and try the link again? – Mike Lohrman Apr 1 '15 at 21:32
  • Success! With a cleared browser cache and FireBug up with persist set (the same thing I did in the answer image) I land at the right url without the 301 and with the anchor retained, and the page jumped to the anchor. Also tried on a different machine with cleared cache. We got it. – jrothafer Apr 2 '15 at 13:18
  • Thanks jchrono-battle, don't know if I would have ever noticed that redirect. – Mike Lohrman Apr 2 '15 at 13:42
  • Excellent, glad to help! ... do I win 100 monies now? – jrothafer Apr 2 '15 at 13:46
  • 1
    sorry, thought checking the answer as correct would do that automatically. you should have it now, thanks! – Mike Lohrman Apr 3 '15 at 21:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.