8 Responses

  1. Brian
    Brian Published |

    And this is another example of something I’ve really never had to worry about, considering Hybrid and Devpress have always made this sort of thing simple.

    I have been dealing with TwentyEleven some recently where I couldn’t choose the theme / framework, and I’m realizing how good I normally have it with hookability / modularity.

    Reply
  2. Ryan
    Ryan Published |

    Thinking through this from a DOM-centric point of view, it would be nice if one could register a function on a specific $post object property name. At least with themes, this would standardize/sync the post filter/event model with the $post object model.

    As a grossly simple example, when $post->post_content is accessed in the WP internals, instead of accessing it directly, it would be passed as an argument to a function that would execute any functions listening to the post_content event and then return the result to the WP internals. This would abstract the filter/event model in a way that would scale with the $post object.

    For $post->post_content specifically, it would make sense to do this in get_the_content(), since this is the final endpoint before it is returned to a theme. It would be tedious to decide on the endpoint for each property, but it would be a great system.

    Just thinking out loud.

    And I could missing a ton of red flags.

    Reply
  3. konradk - wpzlecenia.pl
    konradk - wpzlecenia.pl Published |

    Justin, it looks great and i even can think one step ahead. Imagine that plugin developers, when those template-hooks will be supported, will give for plugin users opportunity to choose where plugin will output its content.

    Evene maybe it could look like this in theme functions.php:

    add_theme_support( ‘template-hooks’, array(
    ‘before_post’ => array(
    ‘screenshot’ => get_bloginfo(‘template_directory) . ‘scr1.png’),
    ‘after_post’ => array(
    ‘screenshot’ => get_bloginfo(‘template_directory) . ‘scr2.png’), )
    );

    in ‘screenshot’ (not obligatory) would be provided url of screenshot of place in theme where plugin content will be outputed. then plugin developers could at plugin’s settings page show this, to help user to choose where to show aoutput

    Reply
  4. Kurt
    Kurt Published |

    I like the idea. It makes sense to me.

    Reply
  5. Henry
    Henry Published |

    Justin,

    For this idea to work there needs to be a central repository where theme and plugins authors can go to find which hooks have been introduced.

    Reply
  6. Emyr Thomas
    Emyr Thomas Published |

    What are your thought on the Theme Hook Alliance effort? Seems to mirror your thinking on the subject.

    Reply
  7. 05/03/2014 — Mr Shoob
    05/03/2014 — Mr Shoob at |

Leave a Reply

By submitting a comment here you grant this site a perpetual license to reproduce your words and name/Web site in attribution.

Please use your real name or a pseudonym (i.e., pen name, alias, nom de plume) when commenting. If you add your site name, company name, or something completely random, I'll likely change it to whatever I want.

css.php