mdsupport wrote on Friday, May 27, 2011:
In many PHP installations, the standard/released code uses require/require_once. The custom changes are implemented using the include/include_once scripts. A site may choose to not install custom scripts without affecting functionality. It makes compact and clear code.
Has this approach been considered?
In a related observation, why do some of the scripts “include” globals.php?
sunsetsystems wrote on Friday, May 27, 2011:
Not sure what you mean by custom scripts. In general, require_once should almost always be used because it’s usually an error when the included script is not found, and we want the error to be caught as soon as possible. There are still many places where include or include_once is used improperly, and I suggest you fix those as you work on modules containing them.
Optional features generally have a “globals” flag, and that should be tested when appropriate. It’s not so good for the back end to waste time looking for included files that will not be found.
mdsupport wrote on Saturday, May 28, 2011:
When we modify the standard (released) code, we consider the script to be custom. It also makes it harder to submit code to the community since we are aware that everyone may not want such functionality. In some cases as we can see with ippf or athletic_team globals, the contribution is compelling enough that the standard code gradually becomes complex with bunch of if … then … else … conditions.
One approach which is moderately scalable is to provide guaranteed custom execution points in the standard code itself. So code such as
Process Block 1
Process Block 2
is released as
include 'custom/proc_block1'
Process Block 1
include 'custom/proc_block2'
Process Block 2
Now everyone can implement their customization of the process in custom/proc_block_n_ scripts which rest of the community does not have to consider. Some package may release empty shells for the custom scripts but use of ‘include’ makes even that part optional. In this community, I am sure everyone is aware of even better and more elegant approaches.
Considering the race to get certified and need to add newer features, it would be wasted effort to touch existing code unless one must. But in the new development it will help everyone if keepers of the standard release require structure that allows for development that will never become standard.
sunsetsystems wrote on Saturday, May 28, 2011:
Introducing a “plug-in” structure for optional features is definitely a good thing, please feel free to propose specific ways to do that. Just wanted to say that using include for a file that may not be present may be inefficient, and as I recall it also causes PHP warning messages to be logged. Also this is an area where an object-oriented approach may be useful.