FURLs with NGINX not working or not right

Description of Problem:
After hours of research and countless permutations of nginx configurations, I just found out that MODx considers a FURL to be:
example.com/about.html AND NOT example.com/about

http://forums.modx.com/forums/thread/29990/friendly-urls#dis-post-162687

The poor soul in this thread had a similar problem years ago and the indicated database/content-type solution suggested therein absolutely does not work. That is to say I've just started to tip toe into MODx's core.

Steps to Reproduce:
This situation shouldn't be reproduced. It should be corrected...years ago!

Expected Outcome:
I'm going to get smoked on Monday. I suggested that we use MODx to evolve a very important internal tool in one of America's largest private organizations. Unfortunately, if there's no way to PROPERLY get rid of the .html, I've got to tell 30+ people that I cannot do what I told them I could because this org has thousands of well established URLs plugged into all corners of God's green earth.

Plea:
Does anyone have a silver bullet for this? Have I missed anything? Thanks!

• MODX Version: 2.4.2
• PHP Version: 5.5.21
• Database (MySQL, SQL Server, etc) Version: MariaDB 10.0.*
• Additional Server Info: nginx - 2015
• Installed MODX Add-ons: None

Ok, here's what I found out:

I can create documents with ".html-less" urls if they are parented with a final child document. For example:

www.example.com/about can be achieved if it has a child like www.example.com/about/ralph.html

www.example.com/about/ralph can be achieved if it too has a child like www.example.com/about/ralph/slug.html

And so on...It seems like all document URL chains will require a redundant child document at the end of the line so to speak.

Even though this situation is like getting an 8-track tape player with a new Aston Martin, I really like MODx and admire the thought and engineering behind it, so I will try to run with this information unless I hear a better approach from an intrepid MODx expert. [ed. note: ralphgoy last edited this post 8 years, 6 months ago.]

In the Content menu, select Content types. Add a new content type exactly the same as HTML (call it HTML blank) except leave the file extension blank. Or, if ALL html pages are to be without extension, edit the HTML entry directly. This should then give you the behavior you're looking for. If you do the former, you'll need to select the HTML blank content type for each document you want without extension. By editing the html content type directly, this will become the default.

Quote from: gissirob at Nov 02, 2015, 05:39 AM

In the Content menu, select Content types. Add a new content type exactly the same as HTML (call it HTML blank) except leave the file extension blank. Or, if ALL html pages are to be without extension, edit the HTML entry directly. This should then give you the behavior you're looking for. If you do the former, you'll need to select the HTML blank content type for each document you want without extension. By editing the html content type directly, this will become the default.

Hello. The link in the original post describes the first solution that you have suggested. I tried adding a new content type row without an extension and this DID NOT work. In fact, none of the pages rendered.

However, I did not try what you suggested next, which is to just change the existing html entry. I'll do this now and report back.

Thanks for the feedback!

Hmm. Certainly the second option has worked for me on a couple of different sites, but this is under Apache2. I would not expect that to make a difference, but you never know...

Also, you may have to manually delete core/cache/* for it to become effective - not sure but it can't hurt.

Tried both suggestions again without success.

But I think we might be ok for now with the dangling child page. This might actually serve a purpose.

Anyway, the next effort is to figure out how to do "smart routing".

Something like: example.com/story/{id:[a-zA-Z0-9]}