So, for a long, long time, the boolean operators on <mt:Entries> were case-insensitive; for example, "foo or bar" worked just as well as "foo OR bar". Sometime between 5.12 and 5.14 (which I finally upgraded to last night), this behavior changed, and now only the documented "foo OR bar" mechanism works. This is fine, and probably a good thing.
What isn't fine is the fact that I never had any warning about this; the old behavior may have been deprecated a long time ago, but I never, say, got any warnings from MT itself about deprecated behavior in a template. So after I upgraded and rebuilt, a lot of my content simply disappeared, because I didn't know about this change. And it's not even a matter of me not checking the release notes, as this issue was never mentioned in any of them as far as I can tell.
It would be nice if in the future there were some sort of warning log that's displayed after a page (re)build operation that tells you about behavior that's known to be changing or broken or the like, to make it easier to track these things down, and hopefully to prevent these nasty surprises from coming up during an upgrade.
Reported on Movable Type 5
You've raised an excellent point with this "or" operator.
The fact that in changed from "foo or bar" to "foo OR bar" is definitely better, because you could have say a category which to contain the word "or" in between two words.
I would say that your input is excellent and Six Apart should implement a warning for this, just as they do for the unrecognized tags.
Would you like to open a feature request yourself for this matter from: http://bugs.movabletype.org/?
If not, I would be glad to do it on your behalf.
Let me know!
Kind Regards,
Mihai Bocsaru
----------------------------------
Daily Movable Type Consultant
Web Development
Movable Type Consulting
Six Apart Partner
http://www.pro-it-service.com/
----------------------------------
Movable Type Demo
http://www.movabletypedemo.org/
Opened at https://movabletype.fogbugz.com/default.asp?108319
Sorry about that. The categories and tags handling were quite buggy, and the code itself was unmaintainable, so I rewrote this part, to fix some other bug.
Probably the 'or' bug was fixed in the rewrite without anyone realizing it.
So that is why you there wasn't any warning - nobody knew about this bug to know that it was fixed! :-)
That doesn't surprise me judging by the way mt:Entries behaved in the past. Thanks for the explanation!
Thanks for your quick feedback, Shmuel!
Good if a warning could be placed on this, just as it happens with unrecognized tags, so that users could update their templates, rather than not having the displayed the content they expect.
Mihai: I can't really think of a way to do it.
we fix a lot of bugs in each release, and touch a lot of code. Getting warnings to the users in an understandable way is not easy.
Sure, you can always read the solved tickets list, but it won't help you so much. As we saw in this case, there are always unexpected results.
What I was trying to propose was more of a means of accumulating warnings during the build pipeline - so that after an entire build completes you can list out everything that could potentially have been a problem. Also, the warnings don't necessarily have to be for specific known brokenness, just things that are potentially a sign that something wacky is going on (for example, "template DateBased: MTEntries tag on line 145 had no entries" or the like).
Or really, just having a temporary build log which can produce detailed output with different message types (debug, warning, error, etc.) that can be viewed after a build — and is automatically shown if there's a warning or error — would be really helpful.
Come to think of it, a better possibility for fixing this particular issue is make it a fatal error if the 'categories' attribute sees a category that doesn't exist. For example, in my case, the string was "Comic or Recap" which of course doesn't exist, so it could have died with the error "No such category 'Comic or Recap'." In the past I've also run into issues on other sites where I'd forgotten to change a category-dependent entry listing when I changed a category name, so even if any entries do appear, it wouldn't get ALL the entries I intended.
Basically I think the 'categories' attribute needs to be a lot more strict. :)
About the build log - we don't have this feature currently. sorry.
As about the strictness - there are people that are playing around with templates. For example, a website pulling entries from various child blogs to create his pages.
In that case, some categories can be only defined in one blog, and not in others. so the filter need to 'skip' those.
So we can't make the filters too strict.
The only thing that I don't understand, is why we cannot use a workflow similar to the one for unrecognized tags.
If you place a madeup tag inside a template and you save, you will see that movable type reports in red above the template content area that the tag "ABC" is not recognized.
I was thinking that something similar, but maybe a warning and in a different color could be reported for this issue that fluffy reported here.