Minimum PHP Version?

[Angryboy]

The wiki says that GetSimple supports PHP 5.2. This version has been off life support for quite some time now (2011), lacks a number of useful features that are now available in later PHP versions, and is open to many security risks.

According to w3techs, PHP >= 5.3 is used by more than 84% of PHP sites.

I guess what I'm asking is this: should the project still be supporting a legacy version of PHP that is as far behind the curve as 5.2 is? Many of the ways we could improve the core code (and plugin development) are marred by functionality that doesn't exist in 5.2, but does in 5.3.

[shawn_a]

5.2 support will be dropped in 3.5

( one of my hosts is still running it, its still out there )

[Angryboy]

Ouch. I knew that there were hosts out there still running 5.2. I was hoping they would be in the severe minority.

It's a damn shame, because a lot of the engineering-based problems that you alluded to in the Hello World topic could be tempered with the tools in 5.3+. Anonymous functions and namespaces alone would help greatly with global scoping in the core and for plugin developers, and neither of these features can be shimmed/polyfilled by client code.

[Tyblitz]

Ouch. I knew that there were hosts out there still running 5.2. I was hoping they would be in the severe minority.

It's a damn shame, because a lot of the engineering-based problems that you alluded to in the Hello World topic could be tempered with the tools in 5.3+. Anonymous functions and namespaces alone would help greatly with global scoping in the core and for plugin developers, and neither of these features can be shimmed/polyfilled by client code.

My reply to helloworld plugin was before I saw this thread... +1 to it though.
Another possible solution is dropping PHP 5.2 support in a 4.X beta version parallell to dev in the 'main' version (I remember Modx had Evolution & Revolution series with this type of strategy)

[shawn_a]

Yeah that is probably the best way to approach 4.0

[Angryboy]

Hmm...if a core with the benefit of those features is on the slightly far horizon, I guess a good question to ask is what architectural changes would you be open to with them available? Because I'd be happy to sketch ideas and/or contribute towards the implementation of set ideas if it is agreed how those tools would be used.

[shawn_a]

The entire plugin system needs to be rewritten from scratch I think.
And it is worth rewriting.

There is a ton of stuff on github about plugin requirements.
Dependencies being a major one.

Plugins that depend on other plugins or extend other plugins.

Plugins that register assets or libraries for other plugins

Settings plugins like theme settings etc

Global namepsacing is a issue,

Plugins must be included to be registered , is a problem, there is discussion of a manifest file.

There is discussion of plugins being inside sub folders and not php files.

[shawn_a]

Oh and the hook system, it has been greatly advanced in 3.4 by me and I specifically wrote it to allow it to be converted too oop. But it also needs improvements.

[Angryboy]

Interesting stuff. In terms of the rewriting from scratch, are you saying that the existing plugins would no longer be compatible with the future system?

[shawn_a]

probably, hence the 4.0 designation

[Tyblitz]

On a sidenote, the 4.x would also be the ideal chance to rethink the already discussed future of I18N. 
I like the idea of a manifest file, especially as an index of the plugin's structure. 

Something that would also be absolutely awesome to have quickly at hand (imo, I coded my own) would be managing a plugin version update. You would simply write a file update.php, include it in your plugin dir, and the file would be automatically run only once when PHP sees that the cached plugin version and the freshly uploaded one don't match. Similarly, i'd always looked for hooks for running code only once upon plugin (de)activation.

As for plugin folder structure (separate folders), other established cms'es can be a good source of inspiration for making a decision.

[Angryboy]

Currently experimenting with a lambda-like wrapper for 5.2. At the time of speaking it seems to work for 5.2.0 upwards. The syntax isn't great, and it still suffers from the problems of create_function, but it's at least a step in the right direction for 5.2 closure compatibility.

A plugin updating system would be grand, actually. And sign me up for per-plugin config files.

As for having plugins be in their own separate folders, that can easily be implemented now without breaking the backend, can't it? Like checking for a plugins/your_plugin/index.php file and loading that if it exists, and reverting to plugins/your_plugin.php otherwise?

[shawn_a]

It breaks extend..

An easy to use config file wrapper for plugins is easy with 3.4, if you want to make one go ahead ill add it to 3.4
The problem without plugin classes, is you have to throw the plugin id around, there is no way to know which plugin is trying to do stuff.

( we register hooks and use debugg_backtrace to log the file and stuff, but this is being removed in 3.4 as it is inefficient and unecessary, so it cannot be used, it is also a non production function )

only register_plugin knows what the plugin id is at runtime, hmm

Maybe a interesting back portable class could be reachable by old plugins.

Code:

$myplugin = getPlugin($thisfile);
$config = $myplugin->getConfig();
$config->addConfig('color','red');
$config->save;

of course making stuff like that plugin useful might be neat

configdatatype extends class plugin.config
plugin.config.adddatatype($configid);
datatype wysiwyg

[Angryboy]

It breaks extend..

An easy to use config file wrapper for plugins is easy with 3.4, if you want to make one go ahead ill add it to 3.4
The problem without plugin classes, is you have to throw the plugin id around, there is no way to know which plugin is trying to do stuff.

( we register hooks and use debugg_backtrace to log the file and stuff, but this is being removed in 3.4 as it is inefficient and unecessary, so it cannot be used, it is also a non production function )

only register_plugin knows what the plugin id is at runtime, hmm

Maybe a interesting back portable class could be reachable by old plugins.

Code:

$myplugin = getPlugin($thisfile);
$config = $myplugin->getConfig();
$config->addConfig('color','red');
$config->save;

of course making stuff like that plugin useful might be neat

configdatatype extends class plugin.config
plugin.config.adddatatype($configid);
datatype wysiwyg

Are you saying that the 5.2 closure stuff breaks extend, or removing the your_plugin.php file?

As for throwing the ID around, that is where anonymous functions could help. You'd create a collection of "curried" functions, and then pass the plugin's id into the curried function in the plugin loading loop:

PHP Code:

$register_plugin = function($id, ...) {
  return function (...) use ($id) { ... };
};

$add_hook = function($id, ...) {
  return function (...) use ($id) { ... };
};

$get_config =  function($id, ...) {
  return function (...) use ($id) { ... };
};

...

foreach ($plugins as $id => $file) {
  $register = $register_plugin($id);
  $hook     = $add_hook($id);
  $config   = $get_config($id);
  ...

  // Closure to protect variables declared within the function
  // Import the above local functions into said closure
  call_user_func(function() use ($file, $register, $hook, $config, ...) {
    include $file;
  });
} 


[shawn_a]

no... lol
extend has to be compatible with subfolders also, first.