[buddypress-trac] [BuddyPress Trac] #6642: BP Template Versioning
buddypress-trac
noreply at wordpress.org
Tue Oct 6 18:35:45 UTC 2015
#6642: BP Template Versioning
-----------------------------------------+------------------
Reporter: hnla | Owner:
Type: enhancement | Status: new
Priority: normal | Milestone: 2.4
Component: Appearance - Template Parts | Version:
Severity: minor | Resolution:
Keywords: dev-feedback |
-----------------------------------------+------------------
Comment (by boonebgorges):
A very big +1 to the general idea. hnla does a good job of outlining the
benefits.
A couple of questions and comments as I check out the suggested
implementation:
* imath's autogenerated changelog.json is very verbose. I assume that, in
practice, we'd only use it as a starting point. In order for the debug
information to be useful, it shouldn't be too verbose. Maybe 'low' item
shouldn't be shown by default (that'd include, eg, documentation changes)
* The changelog entries as displayed on the Templates tab are not very
useful. How do we feel about linking to the changeset? Or perhaps a diff
that shows the changes between the changeset and the previous commit, for
the file alone. Eg
https://buddypress.trac.wordpress.org/changeset?old=10180&old_path=trunk%2Fsrc
%2Fbp-templates%2Fbp-
legacy%2Fbuddypress%2Fgroups%2Findex.php&new=&new_path=trunk%2Fsrc%2Fbp-
templates%2Fbp-legacy%2Fbuddypress%2Fgroups%2Findex.php We can easily
build these links dynamically. A codex page is good too, but that's one
more thing to create manually before each release.
* I like the `@internal` notation. This seems less intrusive to me than
the `do_action()` technique originally suggested.
* Yes, this should only be enabled when `WP_DEBUG`. I feel pretty strongly
about that. If we absolutely must notify the site admin outside of
`WP_DEBUG`, let's do a dismissable admin notice "Hey, some of your
templates are out of date. Enable `WP_DEBUG` to see details, or contact
your theme developer."
* Is there a way we can update/add template file `@internal` headers
automatically? That'd be good as part of `grunt precommit`. Like, maybe
when you commit, it leaves a timestamp or a changeset, and then part of
packaging for release would involve a script that converts these
timestamps/changeset numbers to version numbers. Not a dealbreaker, but it
would make life a bit easier for maintainers.
In general, I think the approach here is good. I'd be OK including
something like it in 2.4 if imath and hnla wanted to put in the work to
complete their `@todo`s.
--
Ticket URL: <https://buddypress.trac.wordpress.org/ticket/6642#comment:5>
BuddyPress Trac <http://buddypress.org/>
BuddyPress Trac
More information about the buddypress-trac
mailing list