Same file name for Pages in a Structure Group

Question

We are migrating content from a published website (from another CMS) to Tridion using core service.

The website has pages with similar names but different extensions in some of the folders. Tridion will not allow to have same file names in a particular Structure Group.

The issue I am facing is exactly the same as explained in this post.

But there is no exact resolution I was looking for.

Is there any way we can keep same file names in Tridion? or can we achieve this in CDS while publishing?

More Info

The requirement is to migrate whole content as-is to Tridion, i.e. we are copying the published file content into a code Component and publishing it using corresponding Page.

For example, if we have an index.html Page, we copy the source of this file into a Component and publish it using a Page. So we get the index.html page as it is after publishing from Tridion.

Problem occur when we have same file names like index.html and index.aspx. We cannot use any other file names as it may break any existing references.

Answer 1

If you are publishing your pages to the content data store database, another approach would be to create the page with a unique filename and associate a metadata field to it where you store the actual filename (including the relative url to it, for example: /section/subsection/page1.php, /section/subsection/page1.xml). Then to ensure those fields are unique within the same structure group (so later on when you query the broker by this metadata to retrieve the page (explained below) you only get one page back) you could implement a simple Event Handler that on Page Save checks for other pages in the same structure group and confirms the field uniqueness within them.

By doing this, you can then in your application retrieve the page by doing a query to the broker by custom meta by searching for pages that contain a given url in their metadata field that you associated previously.

I've done this in the past for "friendly urls" for example, if you have a page, let's say /section/subsection/page.php, but your SEO team decides that the best SEO url to access that page might be: /section/sub-section/, you could associate that "friendly url" in the page metadata and then query for the page in your application using such "friendly url".

With this approach, obviously, the page filename in tridion will be unique and won't match the page filename you are importing. However the page in tridion will contain a metadata field that DOES match the file you are importing and that you will use to retrieve the page content from your application. Now that I think about it, this could potentially work as well if you publish your pages to the file system... as the page metadata will go to the broker anyway...

Answer 2

As @Bart correctly said, "In Tridion you can't have multiple Pages with the same filename in a single Structure Group". You may be able to achieve this (admittedly a bit hacky), would be to use a generic page extension for your templates like ".page", and then include your real extension in the name, so you end up with something like "/rootsg/subsg/mypage.php.page".

Then in your web application (assuming you are not using 100% file based publishing) could always append the ".page" when requesting the pages from the Broker. We do something similar because our SEO persons believes in extension-less URLS, so we append ".aspx" to URLS like "/rootsg/subsg/mypage", where mypage is actually "mypage.aspx" in the broker.

The big downside of this approach is that the Dynamic Linking features offered by SDL need to be overwritten, otherwise they will all return URLs with the extension on them.

Another possibility (even more of a hack), is to publish your content as binaries in those SGs, and then you can get away with uniqueness which includes filename and variant ID. NOTE: I really don't recommend this, but I have done it, and it works.

Answer 3

In Tridion you can't have multiple Pages with the same filename in a single Structure Group, uniqueness of the Page is determined on the filename without its extension, there is no way around this limitation (one could argue that it is wrong, but it is how the system currently works).

Through a storage extension, you might be able to change what is published out (not sure you want to even go that route and if it is fully possible), but that isn't going to solve the problem you have that you can't have these pages in the CMS.

I'm not sure why you have multiple pages with the same filename and a different extension, so without that knowledge I would simply say: your only solution now is to simply rename the duplicate filenames to something acceptable so you can save these items within the restrictions that the CMS offer you.