more functionality

Topics: Business Logic Layer, Controls
Feb 10, 2009 at 1:48 AM
I like the use of the [more] tag to break a long winded post - however i noticed that its implementation has an issue if two posts on the same day are titled the same.  The link will take you to the full text of the newer entry.  Has this been addressed in later versions? (i'm on 1.4.5).

Feb 10, 2009 at 2:07 AM
This doesn't appear to be a problem with just the [more] extension.  It also happens when you click on the post title too (I just noticed).

What's even stranger is clicking on the Permalink also fails!  Even though the permalink is a unique identifier, BlogEngine is looking up the post title based on the guid, and redirects you to the url that has the title in it.  When there's two or more posts with the same title, the more recent post always comes up ... even if the posts were done on different days.

I noticed this behavior in the most recent build of BE (24796).  So, no, I guess it's still a problem.
Feb 10, 2009 at 2:38 AM
Edited Feb 10, 2009 at 2:43 AM
yeah - i just started using BE.N so haven't fully tested everything - but after i posted this I started to wonder what else might show similar behaviour.  Given every post has a GUID, it seems like it should be fixable.  It seems like a serious issue though - I can easily imagine users posting "my thoughts for the day" or something similar again and again.  Worse than having the user always directed to his most recent thought would be someone else who also posted a "my thought for the day" directed to the wrong thought. (if that makes any sense - its getting late here)

It definitely as a problem in the search results: in the search result preview it will show the two different posts, but the links take you to the same post.

I'm surprised it has issues if the the posts were done on different days though - since the link has the yyyy/mm/dd in it.
Feb 10, 2009 at 3:02 AM
Edited Feb 10, 2009 at 3:06 AM
hmm - the problem also exists with file uploads where the file has the same name - it will only return the most recenly uploaded file.  This might be a more serious problem/roadblock for me than i originally thought :(

*edit - actually if two files with the same name are uploaded on the same day, it just overwrites the prior file. I will have to wait until tomorrow to see what the file return behaviour is for files named the same thing uploaded on different days.
Feb 10, 2009 at 3:12 AM
The situation with uploaded images and files is different.  Uploaded images and files go into a folder named App_Data\files\YEAR\MONTH.  So all images/files you upload within the same month will go into the same folder.  If there's already a file in App_Data\files\YEAR\MONTH with the same name you are uploading, it is overwritten.  So this too is sort of a problem ... but it's really a separate issue from the first one you brought up.
Feb 10, 2009 at 3:33 AM
is there a way to modify the code to use the GUID as the permalink instead of a date formatted link?
Feb 10, 2009 at 4:19 AM
I was just looking through the BE core source code to find a "solution" for this.  I have something I'll probably submit in the Issue Tracker.

For what you're asking for, there's a couple of quick things you can do.  If you open up the PostView.ascx file in your theme's folder, you'll find "Post.RelativeLink" is used to generate the non-Guid url.  You can just change that to "Post.PermaLink".

The other necessary change is in the post.aspx.cs file.  Right in the Page_Init event handler, there's this code:

if (!Page.IsPostBack && !Page.IsCallback)
    if (false && Request.RawUrl.Contains("?id=") && Request.QueryString["id"].Length == 36)
        Guid id = new Guid(Request.QueryString["id"]);
        Post post = Post.GetPost(id);
        if (post != null)
            Response.StatusCode = 301;
            Response.AppendHeader("location", post.RelativeLink.ToString());

If you add the "false &&" part I bolded above, then the correct post should show up and BE won't do a 301 redirect to the user-friendly (non-Guid) url.
Feb 10, 2009 at 4:53 AM
I just created this issue for this in the Issue Tracker.

It's a solution that takes care of the problem when the "Add date to post links" option is selected and two posts with the same slug are posted on different days.  The solution I proposed in the issue doesn't take care of two posts with the same slug being posted on the same day and it also doesn't take care of two or more posts with the same slug when the "Add date to post links" option is not selected.

So, as long as you don't have two posts with the same slug in the same day, and if you have the "Add date to post links" option selected, then the solution proposed in the issue tracker should solve the problem when using either the Guid or the non-Guid urls.
Feb 10, 2009 at 10:21 AM
great - thanks.  I'll give that a shot today.

Feb 10, 2009 at 6:42 PM
I guess for this to be effective, all instances of Post.RelativeLink need to be changed.  It does make the links changed above reference the correct post, but the Break.Extension, Search page, email links, etc also need the change.  (no need to post instructions - i can find the references).
Feb 10, 2009 at 7:05 PM
Yes, you're right.  If you're making changes though, you could apply that proposed code I had in the work issue to the UrlRewrite module.  If you did this and are also including the date in the post url, then you might not need to make all the changes you're doing.  Of course I'm not sure what your ultimate goal is ...
Feb 10, 2009 at 9:23 PM
Edited Feb 10, 2009 at 9:29 PM
well primarily i want to be sure that regardless of slug or title duplicity, the correct post is always returned.  If i read your proposed solution right, it would fix the issue for matching titles/slugs on DIFFERENT days, but not address the issue for same day - or am I reading it wrong?

Thinking out loud- maybe an alternative is to append the date/time to the end of the slug at the time of post creation.  - but on a busy sight with lots of contributors, i want to ensure uniqueness.. and including seconds would make that as ugly as a GUID.  It feels like to me, that not using the GUID is trying to re-invent the wheel - creating a unique identifier when one already exists.  So ideally if people are stuck on using some kind of prettified link, they could choose have it in the settings to  UseRelativeLinks set true, and if they are more concerned with data validity, they can set that off...

Feb 10, 2009 at 9:34 PM
Okay, I see.  Yes, the proposed solution in the issue would make sure two posts with the same slug posted on different days would work correctly, assuming the post's date is included in the url.  If there's a chance you'll get two posts with the same slug on the same day, then yeah, you might be best off going with the guid.

Especially if you're going to be offering a 'UseRelativeLinks' setting, then it sounds like you've gotten it taken care of.

Btw, did you decide what to do about the possibility of two images or files with the same name being uploaded in the same month?  If you haven't looked into it yet, you could pretty easily change the name of the image/file saved to App_Data from the real file name to a guid in the Add_entry.aspx.cs file.  The two methods to look at there would be btnUploadImage_Click and btnUploadFile_Click.
Feb 10, 2009 at 9:40 PM
for my purposes the chance of duplicate slugs may be higher than normal since it would be for discussion of stocks - and the users could be lazy and just use the ticker as the title/slug, and could definitely have more than one discussion on a given name.

For the files, i havent looked into that too much since that seems to be an easier problem to deal with (ie there are less instances referencing the file name).
Feb 10, 2009 at 10:13 PM
Actually, being lazy, what I'll likely do for the settings change is add a setting "Use GUID for slug" and if selected, addentry.aspx will disable the slug field and auto-populate the guid.
Feb 10, 2009 at 11:18 PM
Haha ... lazy or not, that sounds like it would work.  Don't forget to disable or hide the 'Extract from Title' link too ...