[wp-trac] [WordPress Trac] #13699: File Header (Plugin Header, Theme Header) Improvement

[WordPress Trac]

#13699: File Header (Plugin Header, Theme Header) Improvement
-----------------------------+----------------------------------------------
 Reporter:  hakre            |       Owner:            
     Type:  feature request  |      Status:  new       
 Priority:  normal           |   Milestone:  Unassigned
Component:  General          |     Version:  3.0       
 Severity:  normal           |    Keywords:  has-patch 
-----------------------------+----------------------------------------------
 '''Summary:'''

 There is a design issue with the current implemenation of how headers are
 parsed from theme and plugin files.

 The main flaw is, that the current code hardencodes concrete header names.
 There has already been an extension to it, so plugins can de-couple from
 concrete header names ([12044]) but in the end, the root cause has not
 been touched: Make the implementation work with (almost) any header name.

 '''Motivation:'''
 Goal is to reduce the dependency within the API from concrete header names
 to make it more flexible for the things to come.

 Next to that, plugin and theme authors can benefit from a better
 implemenation to re-use existing API functions to parse files and to more
 easily add own header names.

 '''Domain:''' [http://codex.wordpress.org/File_Header File Headers] are
 commonly used in the !WordPress project to add meta-information to themes
 and plugins. They are file based and are sometimes optional and sometimes
 mandatory. Basically they are providing meta information for source-code
 files (CSS in Themes, PHP in Plugins) which is used in the backend later
 (The Appearance and Plugins Admin-Pages).

 '''Implementation:''' I made a first step in a two step implementation as
 a proof of concept:

 Step 1: Generic File Header Parsing function[[BR]]
 Step 2: Better use of that function

 For the first step, I've provided a patch. It contains a re-implementation
 of a file header parser that does this independent to header names. Next
 to that it contains various code improvements in the existing function.

 The second step is not yet done and should be done after discussion about
 the generic parsing implementation. One reason is, that in the details
 there are additional flaws which could be fixed as well. For example,
 after the extension to headers in #8964 / [12044], the return array of
 {{{get_file_data}}} not only remains undocumented but keys are named
 inconsistent (plugins can not key them as the core keyes them).

 ''' Benefits: ''' Overall this will help to deal with existing and new
 headers, because discussing and (re-)implementing them does not need to
 alter that many lines of code. This will make things more stable in the
 end.

 Additionally on the social side, discussion can be better spereated
 between technical issues (that string can not be used as header) and
 strategic issues (we need a header named as ...). This will especially
 help developers who are creating patches etc. related to the topic.

 ''' Related: ''' There are some tickets I'd like to list (ordered by
 number) because they are touching the topic:

  * #8964 - Allow adding headers to get_plugin_data
  * #10814 - Plugin GUIDs
  * #12130 - Add Donate URI plugin header
  * #12260 - Add PHP requirement to plugin info retrieved trough API call

 Next to that I've created [http://codex.wordpress.org/File_Header a
 documentation in codex that should be pretty complete in terms of file
 headers].

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/13699>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software