Subscribe to
NSLog(); Header Image

‘_1’ in MovableType Basenames

Several times since upgrading to MovableType 3.2 at The Sand Trap .com, basenames have included a "_1" at the end. I have no idea why, and it's frustrating to have to go through and edit the basename and change the URL of any TrackBacks.

If I could understand why MovableType keeps putting "_1" perhaps I could tell the staff how to avoid getting it (because remembering to check for it has proved futile). Entries are not named the same as previous entries, so that's not the issue. What causes MovableType to append "_1" to the basenames?

7 Responses to "‘_1’ in MovableType Basenames"

  1. Just an idea and I'm sure you looked into it but... maybe the entry has a tile that has a space on the end... "Example Entry Title "

  2. I've noticed this, too - MT putting '_x' after basenames that are not duplicates of existing basenames. I started digging around in the MT code a bit, and while I haven't come up with a conclusive answer, I'm guessing that it may be a bug related to saving an entry and changing its status. Normally, MT only appends the '_x' to a basename if it has found an existing (presumably previous) entry in the same blog that has the same basename as the one currently being saved. So my guess is that this bug is happening because at some point the current entry has already been saved to the database, but then at a later point (perhaps when re-editing or updating the status), MT thinks it needs to generate the basename again. It sees the one it has already saved, and generates a new basename with '_x' appended. Then it saves the entry again.

    I have to dig into the code a bit more to see when and where exactly this is happening, but I think I'm on the right track. Let me know if you hear anything else about this.

  3. I think changing the status is right. MovableType seems to think it's a new entry, or it seems to check the basename before it's realized you're replacing the old one.

    More research is necessary here, but that seems to be the case. That was my hunch too, Peter.

  4. I've received a response from Six Apart support regarding this issue:

    When you save or edit your entries, do you use the preview feature?If so, then you may have stumbled across a newly cofirmed bug where saving the entry (using the "Save this entry" button) from the Preview screen can alter the basename for the entry. To avoid this issue, instead of saving the entry from the Preview screen, if you return to the Edit Entry screen, using the "Re-Edit this entry" button, and clicking the "Save" button on this, the basename will rename the same.We've also observed that if, after the basename has been altered due to the bug, if you go back and save the entry again from the Preview screen, the basename reverts back to the original. In fact, it will switch between the original and the _1 version as many times as you do this! So, if you have noticed entries where the _1 has been appended due to this entry, you should be able to revert to the correct basename by following this procedure.Additionally if you unlock and customize the basename and then do this, you'll "lose" your change - it will switch back and forth between the original basename and basename_1. You will need to unlock the field again to fix it.So, in short, yes, this is now a known issue. We have filed a case for this issue with the developers, and so expect it to be resolved in a future version. In the meantime, the workaround is to avoid using the "Save this entry" button on the Preview screen if you wish to accept the entry as previewed, and instead use the "Re-Edit this entry" button, and then Save from the Edit Entry screen.

    However, since Erik is using ecto, he is not using the 'Preview' function. This may be a related bug. Or perhaps it is the same bug, and Six Apart just hasn't discovered other methods for reproducing it.

  5. Similar problem here with dynamic publishing using Chad Everit'z MT-Notifier. The entry is saved, a notification is sent out to users with the standard base name, but when they recieve it and click on it, the file doesn't exist. If I saved it as unpublished first, then published it, I didn't get an appended basename. At first, I thought it was a problem with MT-Notifier, but it seems like it might fit in to this overall bug?

  6. That may be. The issue seems to be a threading issue, or an order of operations type of an issue. If the entry "posts" to the MovableType script before MovableType realizes it's an edit and not a new entry, then the _1 problem would rear its ugly head.

  7. MT basenames

    Just a bit of Movable Type administrivia, which I'm posting in case anyone else has this problem: ever since I upgraded to the latest version of MT several months ago, I've noticed a bug in which MT will sometimes unnecessarily...