Pretty URLs Setup Problems

[chet]

There was a forum thread back in September with some issues struggling to get pretty URLs implemented. I have a similar issue, but now that we’re months further down the development line, and Elements has progressed so far since September, I wanted to start a new thread.

I’m working on my first Elements CMS blog for HX Aviation. I’ve used Elements Essentials and followed a few of the older YouTube tutorials to get everything up and running.

I have four posts ready to go live, and when I do a local preview, everything looks perfect!

My next step is to get it over on my development site. That’s when things start to go wrong. I’ve spent 3 hours trying to get this to work, and I’m hoping more experienced eyes will quickly spot my error.

My ideal “Pretty url” for each blog post would be: https://flyhxaviation/articles/post-title-here

I added the rewrite code to the .htaccess file, but the individual posts return 404 errors.

Here is the current version of my .htaccess (which is a the root of the subdomain for the dev site). I attempted to use the rewrites in the Elements documentation and the below is from ChatGPT.

RewriteEngine On

# 1) Redirect query URL -> clean URL
# /articles/?item=slug  (or /articles/index.php?item=slug) -> /articles/slug
RewriteCond %{THE_REQUEST} \s/articles/(index\.php)?\?item=([^&\s]+) [NC]
RewriteRule ^articles/?$ /articles/%2? [R=301,L]

# 2) Internally rewrite clean URL -> CMS handler
# /articles/slug -> /articles/index.php?item=slug
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^articles/([^/]+)/?$ articles/index.php?item=$1 [L,QSA]

And here are the settings in the Collection component:

I hope I just screwed something simple up and this will all be up and running with some tweaks.

Thanks in advance for your generosity helping me figure this all out.

[ben]

Hi @chet

I checked the development site and can see that the individual post pages are working with query parameters: Trusted Aircraft Brokerage & Sales | HX Aviation, LLC Copy Copy

The short version is: the rewrite rules don’t match the actual URL structure on your dev site.

On the dev site the CMS posts actually live at /hx/cms/post/{slug} not under /articles at all.

So the core issue is:

• Your .htaccess rules are written to handle /articles/{slug}
• But the real request path on the dev domain is /hx/cms/post/{slug}
• Because Apache evaluates rewrite rules relative to where the .htaccess lives, none of the patterns ever match
• Result: the rewrite never fires → 404

That’s why the query-string version works:

/hx/cms/post/?item=mastering-the-pre-purchase-inspection

but the “pretty” version does not.

To fix it, the rewrite scope and the actual CMS path need to line up — either by:

• moving the .htaccess into /hx/cms/ and rewriting relative to post/, or
• keeping it at the subdomain root and explicitly matching /hx/cms/post/{slug}

Once those match, the CMS handler will resolve the post correctly.

Hope that helps

[chet]

Yes, that’s very helpful!

With some more tinkering, I was able to get the pretty URLs that I was looking for, but this created other problems. The blog post page stripped out all of the spacing and the images on the page were all broken. My links (like the button to go back to the Articles page) would rewrite incorrectly and 404.

Some of this may be just the dev site and fixable on the production site, but I don’t really want to risk breaking something on the live site over how the URL looks.

I’m not a fan of Wordpress, but the one feature that I always appreciated was the ability to simply type in the post slug I wanted and WP did all the heavy lifting. I don’t know if that’s technically feasible for the Elements system, but it would be very nice.

[jbob (jol yates)]

Agree strongly - ability to supply a definitive slug like WP would be great

[ben]

@chet

I’m not a fan of Wordpress, but the one feature that I always appreciated was the ability to simply type in the post slug I wanted and WP did all the heavy lifting. I don’t know if that’s technically feasible for the Elements system, but it would be very nice.

The filename is effectively the slug for a post in Elements CMS. Unlike WordPress, there’s no central database layer where the slug is stored independently from the content, so the system relies directly on the filesystem instead.

In practical terms, this means the name of the markdown file is the slug. For example, a file named welcome-to-elements.md will be published at a URL ending in /welcome-to-elements. If you want to change the slug, you do so by renaming the file itself.

However, there’s an important caveat: Elements currently doesn’t sync renamed markdown files with what already exists on the server. So if you rename a file and republish without removing the old one, you’ll end up with two separate files on the server — the old filename and the new one — which results in duplicate posts appearing.

Let us know if you need any more help

[chet]

The part of the URL in the default Elements output (no .htaccess) work that bothers me is the ?item= prefix that goes on the slug. I’m sure there’s a technical reason for it, and honestly most web users will never notice it.

Elements gives me total control to refine virtually every single aspect of the visitor experience natively that finally makes dealing with responsive design manageable. It really sets me up for success. I think that’s why this pretty url issue is such a big deal to me: the rest of my site is perfectly laid out and calibrated, but on the blog URLs I have extra characters/words that break that perfection.

I would prefer if the default output, without requiring additional steps by the user, would be that when you publish the file welcome-to-elements.md, the published URL is /welcome-to-elements instead of /?item=welcome-to-elements

Again, I’m sure there’s a technical reason for the ?item=, I just hope there’s a way to omit it on the published site by default.

[Pegasus]

Basically, I understand what you mean.

However, the ?item= prefix cannot be avoided for technical reasons. It already existed in ALLOY and TCMS, and it’s the same in TCMS3 as well.

If you want to get rid of the prefix, the only option is to use a redirect via .htaccess.

Alternatively, you can do what I’m currently doing:

You manually create the individual page for each blog post directly in Elements. This approach actually has two advantages at the moment:

1. You don’t need any .htaccess redirects.
2. Your URLs will be indexed by Google. With the “standard” blog CMS usage, there is currently still a canonical issue, which is why the blog post pages are not being indexed properly.

In principle, this works the same way as setting up a normal blog — the only difference is that you manually link the ITEM to the corresponding .md file each time.

[chet]

My ideal situation would be a clean url: https://flyhxaviation.com/articles/mastering-the-pre-purchase-inspection

Apart from the ?item= being in the slug, Elements pulls in the Item Template Page Name into the URL. That’s fine, but I want the landing page for the blog /articles/. I can’t have two pages with the same name (the actual blog page and the CMS item template page), so I give the item template page “Insights” and now I have /articles/insights/, another layer in the URL that I’d prefer not to be there.

I could also move the folder with the markdown files into the blog Articles page group, but then the url is exported /insights/?item=post-title and the /articles/ is completely gone from the url.

I know myself well enough to know that if I go down the trail of /articles/insights/?item=post-title, I will look back in 50 or 100 blog posts, find a solution to get to my ideal URL, but then need to do all of those redirects to make it solid.

I’m going to use the super powerful globals to build single pages for each post and use the handy overrides for the blog-specific text/titles/pictures.

The CMS system is great, and I know it’s in beta. I need to get the blog going on this site, I think that need is just too early in the development cycle for the CMS system to be the right fit. I’m sure I’ll use the system on a future site as the CMS grows and matures.

[thominator (Thom Hogan)]

I’m a little unclear about what you’re doing here, though the way you word things is intriguing.

Are you saying that you create “Post” page for each Markdown file and aren’t using Collection, per se? In other words, using the following to point to a single MD file:

If so, what are you doing about collections?

[Pegasus]

Yes, that’s correct. That’s exactly what I’m doing.