Re: [habari-users] "themehelper" plugin
Ali B.
I personally don't have problem with either. So to let others decide I copied the habar-dev list.
Sorry for the question, but do we really need that plugin? Most themes
use their own comments URL call. And the plugin actually does not
support closed posts. Can we talk about having it in the core?
Don't get me wrong here, guys. I'm not trying to turn Habari into
WordPress. But you have to admit that some things are very convenient.
And some kind of a standardized call for the comments link, for the
author, for the edit link could make the theme development much
easier, don't you think?
--
Ali B / dmondark
http://www.awhitebox.com
Owen Winkler
> Sorry for the question, but do we really need that plugin? Most themes
> use their own comments URL call. And the plugin actually does not
> support closed posts. Can we talk about having it in the core?
If the plugin does not support something, it should be filed as a bug.
I don't understand what it doesn't support based solely on what I've
read here, so please be a bit more detailed when creating the ticket.
There is a specific reason that the plugin is a plugin and not a core
feature: Some of the functions it can provide, like the output of the
paginator, should be generic but replaceable with other functions. In
other words, if an admin wants to use a different style of paginator, he
can replace the plugin with one (or add an additional one) that provides
the functionality he needs, using the same function calls and
parameters, but producing different output.
If we include all of these functions in core (not as a plugin) then this
capability will be more difficult. If there is discussion about this
plugin's functionality moving back into core (it was separated from core
into a core plugin for the reasons provided above) as suggested in
http://trac.habariproject.org/habari/ticket/341 then we should have that
discussion here.
The reason why this feels so sketchy right now is because plugin and
theme dependency features are weak. I would really like to see
development of stronger required/recommended features in an upcoming
version of Habari. This feature would not be as some themes have
started doing - requiring specific plugins by name - but by requiring
functions by signature.
Themes, for example, could require that something in the system
implements a specific plugin hook with a specific parameter signature.
If nothing does, then the theme would not activate and would provide a
warning. The use of a function name and signature as opposed to just a
plugin name is important because it allows things to continue to
function between versions as long as the signature of the function
remains the same. An additional phpdoc comment might be added to the
function declaration to override the signature of the function if the
internals of the function change such that it becomes functionally
incompatible with prior versions.
If a requirement is not met, the requirement procedure could indicate
solutions to the problem, such as a specific new plugin that is known to
provide the needed functionality, or the name of the core module or
plugin that provides the existing function name that fails to meet the
signature requirements and likely needs upgraded.
Essentially the question changes from "Do you have version X.Y of a
plugin?" to "Do you implement this feature in the way that will be
used?" which is much more flexible.
Fundamentally, this may be the secret to avoiding upgrade issues with
plugins that plague other platforms, since themes and plugins will be
able to continue to work after version upgrades (since it checks the
function itself, not any version number) and information about what
causes things not to work will be available before and potentially after
changes are applied.
Developing the above with a facility to provide an upgrade template
could allow users to test what may break after an upgrade by uploading a
set of signatures for the new version and testing them against the
requirements of what is already installed.
How all this applies in this case is that themes can (or not) require
the functions within the themehelper plugin for activation if they use
those features. It would be nice to augment the offerings within that
plugin.
> Don't get me wrong here, guys. I'm not trying to turn Habari into
> WordPress. But you have to admit that some things are very convenient.
> And some kind of a standardized call for the comments link, for the
> author, for the edit link could make the theme development much
> easier, don't you think?
There is a fundamental desire not to call functions directly from within
the theme. If the suggestion is to create a ton of static "helper"
functions that simply output things that could otherwise be echoed, I'm
an opponent of that idea.
Still, it might be useful to add some additional basic features to
objects. For example, we could produce a value for $comment->url so
that when you output it, a uniform, global URL is produced for any
single comment.
There are some enhancements that we need to make to generic string
output that might also be useful. We should create a String class that
can filter content, and us it to supplant the existing Filter system.
Currently, we have code that supports echoing $post->content_out through
a filter. What I would like to do is change this system so that
$post->content is not just a standard PHP string, but a new
Habari-provided String class. You could use it normally via
$post->content and the __tostring() magic method. Using it as an object
would make additional features available for output.
For example, the filter created by filter_post_content_out() would then
apply to echoing the property of $post->content->out, which would also
return a String object, but with the filtered output. The filters could
then be chained, if need be.
We could also provide some core filter functions that allow use to
better manipulate strings internally. For example, we might offer a
->attribute filter that filters a string so that it can be a valid
parameter to an HTML tag. Likewise, we could produce an ->escape (or
something with a better name) property to make sure that something like
$comment->content->escape is properly escaped for output and prevention
of XSS. Just as an example.
This use of a String class would extend to the return values of plugin
theme functions, which should be returning something more uniform, and
whose current operation is a bit confusing.
Calling the ->out() method on a String class could cause the string
value to be output, maintaining our uniformity for this function call
within objects across the project. $post->content->out() could execute
both the out filter and output the value (via the __call() magic method,
although I'm not yet sure if this is the best idea or if we should
implement out() explicitly as a method on the String class), whereas
$post->content->out would simply return the value as a property is wont
to do.
To make things easier for theme developers, we could add hooks that
allow plugins to extend the properties of our core objects. So you
could create a plugin that would add a URL property to User objects that
would point to user-specific pages. You could then output
$post->author->url to get the public URL for a specific author's posts.
The above is just an example, as this particular feature might actually
be better as a core feature since the rewrite rule for an author page
should be something internal to Habari core. The same could be said for
the edit link for posts, since that URL is fixed within the admin.
Likewise, a similar thing for the Post object would allow plugins to
bind external data to Post objects that represent alternate content
types. But that's digressing a bit from the purpose of this message.
Anyway, I think that it's reasonable to say that these things are not
currently as easy for theme developers to do as they could be, but I'd
like to first see a list of what's not easy, and then decide how to
implement those things in a Habari fashion.
Owen