I had (without thinking about it) created an article that had the date in a parseable form ( for example "2011-08-01" rather than "01/08/2011"). What was happening was that the article url (for example from the home page) had today's date in the url. For example article date was 2011-08-01, however article url was /2011/08/04- (today) - obviously clicking this link took you to a 404.
I added a test and narrowed down the problem to line 242 in toto.rb. It seems when there is a valid date, the yaml loader parses it into an actual Date instance rather than keeping it as a string. This means an exception is thrown since Date doesn't have the gsub method so it defaults to today.
The quick fix I added was to add a check to see if the :date was already a Date.
Although this came about from my mistake (so you may not want this fix) - it was really annoying to track down so I would be really keen at getting some kind of warning/error when this happens to appear in the logs or something. Happy to do this work - just let me know.
Also, I note that in the file, there is a comment "use the date from the filename, or else toto won't find the article" - however it doesn't do this. The #merge at line 253 overrides whatever came from the filename regex with what is in the "meta" block. If the meta block's date is out of sync with what the filename actually is you will get links to nowhere. So maybe this needs a bit of a tidy up/clarification - again happy to help out.
Added test case for failure. When an article contains a proper parsea…
…ble date the article url points to today not the article's actual date.
Added check to prevent attempt to re-parse date when the yaml loader …
…has already passed the date found in the meta section. Which fails due to lack of gsub on the date instance.
I believe that's a good patch. Never ran into this problem, but can imagine that I could.
I have changed my mind :)) Of course we can put lots of safety restrictions and extra tests, but this only bloats (IMHO) toto. So if we are talking about "parsable" date, we must understand that it's not only 10/08/2011 and 2011-08-10, but also 10.08.2011 and 08/10/2011 and lots of other combinations (depending on locale).
This pull request is also related to comment on another issue:
Sorry, I was a little bit unclean... "I have changed my mind" was related to the idea to allow enter dates in different formats. Not about patch fixing "bogus" places in toto :))
Sorry, I am thoroughly confused - maybe I wasn't clear?
If date is set to something "parsable", the YAML library parses the date. Then on line 242 it calls gsub to parse the date from a string. If it is already a date, an exception is thrown and the article's date is overridden to be Date.today in the rescue block.
That is all my patch does, checks if it is already a Date instance, if so it doesn't try to parse it.
What am I missing?
Oh! Sorry my bad - seems like I was going to fall a sleep at that time as only after your words I understood the problem and read patch well. Yes you are totally right. This is a must have.
No problem at all.