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.

  • added a rather basic answer, since you neglected to explain why you have the requirement of pages with the same filename and a different extension. If you edit your question and provide that detail, I could possibly update my answer to contain more useful information for you. Jul 13, 2016 at 11:41
  • added more info @BartKoopman Jul 13, 2016 at 13:41
  • Thanks but still I don't see why you would need index.aspx and index.html in the same Structure Group, other than that you have those in the old system (in which case I think you need cleanup before you migrate?). Now I could understand you needing a index.aspx and index.aspx.cs file (which also is impossible by default in the CMS by the way), in that case I think you should reconsider your migration strategy by the way. Jul 13, 2016 at 13:58
  • I agree. But before decommissioning old system the requirement is to move the whole content as it is. In some case there are pages like index.aspx and index.asp which have different content altogether. Jul 13, 2016 at 14:07
  • 3
    I suppose you could have a situation where supporting filenames may be the same (myContact.aspx and myContact.xml and myContact.css) << I'm not advising but reasoning it's feasible. I think the core issue here is clearly migrate whole content as-is and just stuffing items into code components. I'd really avoid this approach as Tridion is a Content Management System and not a content dumping ground; clients are quickly disillusioned when they realise the inflexibility of this approach. Jul 13, 2016 at 14:27

3 Answers 3


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...

  • I guess this still suffers the Dynamic Linking issues that Chris mentions; but given the content is being shoved into 'code' blocks I suspect it's all hard-coded URLs anyway. Which begs another question.. ;) Jul 13, 2016 at 14:30
  • Of course, dynamic linking will have to be extended... to first resolve the tridion page url, then load its meta and return the "friendly" url from its metadata isntead. Jul 13, 2016 at 14:32

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.


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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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