Back again with the main problem of Piwigo I think : prefilters !
So I finally took a look at a basic Wordpress theme (Twenty Thirteen, is to Wordpress what Elegant is to Piwigo).
I skip the fact that they don't use a templating system but include PHP inside HTML (or HTML inside PHP, as you want :D ) and those "template" files are executed in a special context (Classes I guess)
So I though about a system similar to triggers, there would be two kind of those triggers (template function) :
- trigger_change, exactly the same purpose as PHP trigger_change (former trigger_event) : modify a existing content
- trigger_insert, would act as a marker to insert new content, this could be raw content or another .tpl file (why not with an optional array of variables to pass to Smarty)
In this system :
- we keep prefilters, for very advanced usage and backward compatibility
- we keep "index_buttons" and "picture_buttons" I added in 2.5 (and perhaps generalize the concept to other parts)
Offline
Hi
what's wrong with prefilters according to you? Could you just explain a little bit why we would change and what would be the benefits
As far as I understand, you mean that instead of using a trigger + a prefilter, we would use only those new trigers?
trigger_insert would be redondant with trigger_change used with concatenation of the content?
Offline
Prefilters are :
- complex, when you want to search the end of a block (no significant tag), and require regex for such cases
- fragile, for template interoperability (cf: how painful it was to make some of my plugins compatible with Zaphod themes)
No I don't meant to remove the usage of PHP triggers, well it depends : sometimes I create a trigger which is only used to set a prefilter (for code clearance), in that case I could only use a Template trigger.
I my mind there will be many trigger_insert : loc_begin_picture_comments, loc_begin_comment, loc_end_comment, loc_end_picture_comments (mind the "s") loc_begin_picture_info, loc_end_picture_info, etc.
trigger_change would only be used for some specific case : the title, the breadcrumb (this require a change already asked : don't build the breacrumb in PHP but in the Template).
Perhaps this trigger_change is useless and could be replaced with additional triggers PHP side.
Offline
Ok thx I do understand much better :)
So we would have to map the template files, and use then trigger_insert('content', loc_begin_picture_comments). So that would be the first step to easily 'widgetize' the themes/template.
That's a good idea
Then we could have some zone, which would be more complexe to allow full 'widgetisation', like the current Wordpress system
About trigger_change, I don't see the need for plugins to change tittle/breadcrumb constructions: we should have a better generic way to build them in the template -so the user can change easily the display/construction- and as usual the plugins only transmit the values. Because for me, what you propose means the plugins has to build itself the title/breadcrumb/whatever
Offline
hello,
I'm not very convinced because I cannot see a clear example when it is useful. Can you give a nice example ? (trigger_xxx will be in tpls or in php ?)
Offline
perhaps "trigger" is not the best name, confusing about PHP ones
I am only talking about template.
I don't know what I can say for example, ANYTHING, if we add fully qualified names, and use them in all themes template files it will allow to designers to completely change HTML without consequence on plugins
Look at amazing Mikfle themes : none of my plugins are compatible with them, because he started HTML from scratch (thus prefilters are broken), if he had the same trigger_insert as the default template it would work
Offline
I already gave example of such triggers for picture.tpl
{trigger_insert name="loc_begin_picture_info"}
{trigger_insert name="loc_end_picture_info"}
{trigger_insert name="loc_begin_picture_comments"}
{trigger_insert name="loc_begin_comment"}
{trigger_insert name="loc_end_comment"}
{trigger_insert name="loc_end_picture_comments"}
Perhaps I can't explain myself well but I honestly think it would be a real plus
Offline
hmm
so it's your original idea of mapping the templates with tags to identify where is the comments, the picture, the descrition etc
that's a good idea which could go further, extending what you did with "index_buttons" and "picture_buttons" to add content from a plugin and leting the theme handling the display/html
Offline
mistic100 wrote:
- we keep "index_buttons" and "picture_buttons" I added in 2.5 (and perhaps generalize the concept to other parts)
:)
it could be done for "image infos" for example and certainly other parts, but not everything
and it should be a general function (actually two: one in PHP, one in Smarty), not like I implemented buttons
Offline
yep I see
In fact I wrote the sentence differently originally: I went to even further about blocs on index and generic pages. Currently plugins use Additionnal Page, itself using its own template or the one of the theme, if provided. That -new- way, plugins could itself and easily add their own content, and theme would be able to add their own html
And later on, a complete widget system where Piwigo recognize where a plugin want to add content on such area -common area to add blocs not all-
Offline
I don't really understand, looks like you talk about two different concepts :
- "widgets", I don't understand how you would like to implement them, and how it is different from $PLUGIN_PICTURE_BUTTONS
- "template supercharge" by the theme, I remember we already talked about that and my point of view didn't change : if the plugin make important changes to its template (new variables, renaming, etc.) we will need to wait for an update from the theme, I think this workflow is unacceptable
(I didn't even know that themes could change Additional Page template)
Offline
mistic100 wrote:
I don't really understand, looks like you talk about two different concepts :
- "widgets", I don't understand how you would like to implement them, and how it is different from $PLUGIN_PICTURE_BUTTONS
- "template supercharge" by the theme, I remember we already talked about that and my point of view didn't change : if the plugin make important changes to its template (new variables, renaming, etc.) we will need to wait for an update from the theme, I think this workflow is unacceptable
(I didn't even know that themes could change Additional Page template)
without going to far in the "out of subject":
2) I mean only a generic form like you did: <div class="bloc_truc"><h2>{$title}</h2><div class="bloc_truc_content">{$content}</... and NOT <div class="bloc_truc"><h2> {$title} - {$sub_title}- {$specific_counter}</h2><div class="bloc_truc_content"><form><input id={$truc}>... like we talked.
1)see WP; that's not different, that's just something the user can manage, so an advanced version of "just letting plugin adding their content successively in an automatic order"
Offline
1) Ok I get it, I think by default ranks should managed by plugins themselves, and we can create a plugin which manage ranks
2) No I don't get it :( what is the advantage ? if only the "containing" structure can be changed it's already achievable with pure CSS (in general)
And I still can't imagine the workflow : do themes have to handle every plugin ?
Perhaps I'm totally lost and you should make a concrete example
---
what we are talking about is complementary to trigger_insert right ? we can't add widgets spaces everywhere
Offline
mistic100 wrote:
I already gave example of such triggers for picture.tpl
{trigger_insert name="loc_begin_picture_info"}
...
not sure. themes should still be able to control the final output...
Offline
currently there are not neither...
I'm ok with that, but don't have any (SIMPLE to use) idea about how to implement it, do you ?
the original subject was fragility and complexity of prefilters, for what I propose this solution of markers (+ widget like)
Offline