[wp-trac] [WordPress Trac] #42855: Add ability to filter header, sidebar, searchform, footer and template_part file paths

[WordPress Trac]

#42855: Add ability to filter header, sidebar, searchform, footer and template_part
file paths
------------------------------+------------------------------
 Reporter:  atanasangelovdev  |       Owner:
     Type:  enhancement       |      Status:  new
 Priority:  normal            |   Milestone:  Awaiting Review
Component:  Themes            |     Version:
 Severity:  normal            |  Resolution:
 Keywords:  has-patch         |     Focuses:  template
------------------------------+------------------------------

Comment (by MikeSchinkel):

 Replying to [comment:12 joyously]:

 > I'm saying that they would not be accomplished by filtering the part
 name, as proposed.

 I am sorry but I have to disagree with that.  But I will instead discuss
 actions as they work for me as well, assuming they are provided with the
 name of the "post" template file that was loaded.

 > so the current method would be to know the order they are called in so
 that the next one can do the finish work on the previous.

 That would add to very fragile code that could easily conflict with other
 plugins. Certainly you are not advocating for this?

 > Or, add an action for `all`, and apply logic to the action names that
 start with `get_template_part`.

 Using the `all` action is an anti-pattern because it requires processing
 for every single hook on a page load, which can measure in the thousands.

 If the `all` action were sufficient, WordPress would not have added all
 the different hooks.  Certainly you are not advocating that we write
 plugins using the overhead of the `all` action?

 Besides `all` cannot see local variables such as the context often passed
 as parameters to hooks it is not even a substitute in many cases.
 Including these.


 > Or, any filtering of the HTML should be done on the client end.

 Again, almost anything that needs a named action or filter could filter on
 the client end. That is handing the surgeon a sledgehammer when they ask
 for a scalpel, and it is also fraught we incompatibility with other
 plugins. Certainly you are not advocating for this?

 Can you please explain the explicit scenarios that you fear such that you
 are making proposals that can result in plugins breaking other plugins
 rather than concur that these hooks are needed and have been needed for a
 very long time?

--
Ticket URL: <https://core.trac.wordpress.org/ticket/42855#comment:13>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform