id,summary,reporter,owner,description,type,status,priority,milestone,component,version,severity,resolution,keywords,cc
13699,"File Header (Plugin Header, Theme Header) Improvement",hakre,,"'''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].
",feature request,closed,normal,,General,3.0,normal,maybelater,has-patch dev-feedback,gautam.2011@… chip@…