we had decided to adopt the PEAR Codings Standards(PEARCS) for CMSimple_XH quite a while ago. Recently I found PHP_CodeSniffer (PHPCS), a tool which checks if code complies to these standards. I thought it would be a good idea to integrate PHPCS to our QA, so I integrated a rule "sniff" (might get a better name) to the Makefile, and checked and fixed all core PHP files[1] accordingly (r558-560). Besides DocBlock and formatting issues, which were easy (albeit time consuming) to solve, there are issues regarding the names of functions and methods. The PEARCS don't allow underscores in method names, and they regard underscores in function names as package name separators (the latter is particularly useful, as these package names can be changed to namespaces in the future, which are already available since PHP 5.3 which was released nearly 4 years ago).
Some of the offending identifiers may be simply renamed, as they are not used outside the core (e.g. admin_menu() -> XH_adminMenu()). But some of these functions/methods are already used by extensions (e.g. evaluate_scripting() and PL_Page_Data_Router::add_interest()), so we can't simply rename them. However, I would rather appreciate to deprecate them for XH 1.6 and remove them in the future. That's somewhat viable for the functions, as these can be defined as "aliases" for the core:
Code: Select all
function evaluate_scripting() {
return XH_evaluateScripting();
}Code: Select all
if (!function_exists('XH_evaluateScripting')) {
function XH_evaluateScripting() {
return evaluate_scripting();
}
}And we have to consider another special case: the editor API. This currently uses the functions include_editor(), editor_replace() and init_editor() (resp. their counterparts for each editor, e.g. include_tinymce(), tinymce_replace() and init_tinymce()). We may consider renaming include_editor() to XH_includeEditor() and include_tinymce() to Tinymce_includeEditor() (and the other functions accordingly).
As this would have quite some impact on plugin developers and CMSimple 4, I don't want to propose any particular change--let alone put that on the roadmap for voting. Instead I'm hoping on the opinions of the affected parties--perhaps we can find a good solution.
[1] I have not yet given up the hope, that there will be found active maintainers for the standard plugins, which currently have none (i.e. filebrowser, meta_tags and page_params).
Christoph
PS: [2] IMO we should stick with PHP 4 compatibility for CMSimple_XH 1.6, but I strongly recommend to drop PHP 4 support for the following version (be it 1.7 or 2.0). PHP 4 reached its EOL more than 5 (!) years ago, and its definitely not up to support state-of-the-art programming.