We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
    • 39404
    • 175 Posts
    stalemate resolution associate Reply #11, 13 years, 7 months ago
    Hi theoretiker and opengeek,

    I had an issue with friendly urls not working a few months ago, and I struggled with it for over a month before I figured it out. I don't know if my situation is like yours, but I'll post what I found for you to check.

    friendly_urls broke because I had WayFinder installed and I didn't provide a Menu Title for some resources which had long titles. At first they seem to have nothing to do with each other, but I'm guessing the friendly_urls rewrite rule takes place after WayFinder does its work. When WayFinder found a title that was too long, it died and made friendly urls fail.

    Hope this helps,
    Tom
      • 38304
      • 68 Posts
      Hi Tom!!!

      Thank you for your reply...
      but i don't use wayfinder actually.. because its an config test / lerning purpose... its hardlinked...the pages are pasted pure plain html without using any modx modules actually.

      Thank you!
      Chris
      • discuss.answer
        • 22303 MODX Staff
        • 10,725 Posts
        If you want MODX to serve the .html files, then you have to remove it from your location match which is setting the expires header. You cannot deliver HTML content types from PHP with expires headers, as that cache the result of a potentially dynamic page on the client's browser, and it would never know if you made a change to the page, or there was time-sensitive content being delivered. This is how PHP scripts work. You should NEVER, EVER remove the html Content Type from MODX. The rules work as expected otherwise.
          • 38304
          • 68 Posts
          Crazy stuff... Jason is right! Great suppport Jason!!!

          for everybody like me... searching for a answer about a week...

          Expires on htm/html seems to be the cause.

          I just made the changes...
          - redone the .html extension in Contenttypes... (which i had removed before)
          - removed the html/htm caching in expires nginx rule.
          - cleared chache some times...

          Now it works.

          So it seems that the htm/html expires rule in nginx conf was the cause since beginning because everything is rolled back but the htm/html line in expires rule.

          I am happy now to have a performant modx install (manager is a bit slow but no wonder on this hardware) on microsd at Cubieboard...
          crazy attempt... but good performance for small developement homeserver or hobbyist Projects...

          i will spread the image i think...for other Cubieboard Users so cool...

          Thank you Jason for all that support!

          with best regards,
          chris
          [ed. note: theoretiker last edited this post 13 years, 7 months ago.]
            • 6470
            • 69 Posts
            Hi
            Even this topic isnt new, this problem always instantly arise after Nginx config, Also this resource come first in google search,
            here are my few cents, in case you want to skip digging mindbraking topic


            if you have this problem, most probable
            yourdomain.conf has

               location ~* \.(html|htm|txt)$ {
            	#add_header Pragma public;
            	add_header Cache-Control "public, must-revalidate, proxy-revalidate";
            	access_log off;
            	expires 1d;
            	break;
                  }
            

            somewhere or in included file such as
            include /usr/local/nginx/conf/staticfiles.conf;

            you just need to comment it

            and if you really have static resources or html to serve better rename them, or introduce more complex path based nginx rule policy
            Surely you should not delete html contex with modx not to ruin its functionality