[buddypress-trac] [BuddyPress Trac] #6642: BP Template Versioning

buddypress-trac noreply at wordpress.org
Tue Oct 6 20:52:19 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 hnla):

 Great comments @boonebgorges & @DJPaul thanks guys - I can respond to some
 imath better for others.
 >hnla does a good job of outlining the benefits.
 It must be said though with a lot of collaboration from imath in preparing
 ticket and bpdevel post.
 >Putting a version history/changelog in the template files is a good idea
 regardless of anything else.
 In many ways this was partly the thought here, however it's eventually
 used / extended the principle here is a good one and if we only get all
 the templates docblocked for 2.4 it'll be a great start.

 Yes the changelog is somewhat verbose, personally I tend to like the
 verbosity, the level of detail, however it's a good point in maybe not
 showing the minor changes.

 Linking to changesets rather than changelog? yes can see the point, as for
 codex page I did set up a section a while back to list specific template
 changes by release version  showing the changes required. I defer to Imath
 for what's reasonable or possible to link to.

 >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."
 Think that's a sensible idea. WP_DEBUG is definitely the switch to avoid
 alarming non techie users and messages if seen by them must not alarm or
 suggest their site is about to collapse.

 Questions on docblocks are best left to yourselves to ponder I thought
 @internal seemed a logical choice.

 >how it will help "us" core developers in future
 I think in the sense that we are secure in the knowledge that we're
 directly imparting the changes, and developers are far less likely to miss
 some new feature/ important change.

 >What happens if I don't want to, or can't? Can/should I be able to
 dismiss the errors?
 Don't then! :) Only developers will see these so we assume they can deal
 with the changes. These are not necessarily errors though, however  a
 means to dismiss them? perhaps not a bad idea, although updating their
 template version stamp  would do this, or simply ignoring the tab, I think
 as it's seen vis WP_DEBUG that developers would deal with updating their
 overloaded templates.

 >How (do I make that change?)
 When we have finalised where to link to they will have examples of what to
 change/update and we'll make things clear in those lines of text before
 the template version notices start.

 >Therefore, have you considered the different importance of changes?

 Yes and no, this is a first but very strong draft if you like, we're
 verbose in reporting all changes and maybe that's good? Aria might not be
 critical or a 'feature' however not a bad thing to point out we have
 improved our template with? In addition note that we do highlight what
 changes we do consider are the ones important to attend to ( a better SC
 will be seen in the bpdevel post when it's published)

Ticket URL: <https://buddypress.trac.wordpress.org/ticket/6642#comment:7>
BuddyPress Trac <http://buddypress.org/>
BuddyPress Trac

More information about the buddypress-trac mailing list