we're not relying on overriding url::site() to do tricks around item
urls. This means that you won't get item urls by doing
url::site("albums/37"), for example, but it also means that we won't
get pretty urls where we don't expect them (like in the action of a
<form> element).
Incidentally, this will help us move over to using the slug format
because if you've got a bad character in a url, the edit forms will
now work on it since they'll be id based.
approach using html::specialchars and purify uses HTMLPurifier to intelligently
cleanse the output fields. Use purifier for text and title fields where it is
likely that a user would enter html to format their data.
* Allow for the "movie" type in all of our text
* Try to follow the pattern of mainly only passing ORM objects
to the view and let it generate its own text (this becomes
even more important when 3rd parties want to customize notification
messages)
* Rename _send_message to be _notify_subscribers to be more acccurate
and have it explicitly take a subject in the API
* Use Item_Model::url() in the views instead of hand crafting URLs
* Reformat HTML in views
* Use $comment->author_xxx() functions instead of replicating that code
* Fix several places where we were encoding data by doing ucfirst($item->type)
with conditionals where we form the text properly. We should *never*
be showing data types to the end user! This is not localizable!
Note that this probably breaks the existing batch processing code. I
am going to redo that in a subsequent pass.
