[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

 A couple of questions and comments as I check out the suggested

 * 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
 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