Bug-fix/cosmetic releases?

[hameau]

Hello,

Now that the dust has settled after 3.1's landing ... ;-P

I would like to request consideration of minor point releases addressing minor bugs, niggles and cosmetic issues during the life of a production version. I'm thinking of things like the 'GetSimple Upgrade needed' bug that was discovered immediately after the release of 3.0 and remained for all new downloads of that version for the best part of a year.

I know that these things are pretty small in the scheme of things, but they do reflect disproportionately on the quality of the whole package. I'm not sure that "Oh, you can ignore that warning." is a reasonable response. ;-) I'd emphasis that these would only be for minor fixes, so as to minimise the risk of introducing other problems and (ideally) wouldn't trigger an upgrade warning.

[shawn_a]

Agreed, I imagine there aren't that many though.
Everything is working pretty well.

I know the new plugin system is a bit wierd, it uses ajax activate and deactivate, but there is no load lock or indicator. So you can click on a few in a row and it gets all wonky.

Also when adding plugins the plugins detects them but another reload is needed to see any new tabs or sidebars, or even the details of it. Also it only detect new plugins if filecount changes, so dont rename or remove and add plugins at the same time, this should be a file collection md5 or something instead.

Also the new page caching is very annoying, it occurs upon header hook, which causes a bunch of IO on all xml files on page load. This causes a noticeable delay when working in the back end.
All caching should be moved to a delayed processing after flush() , or a async ajax call or a fork perhaps.

Some other php caching features such as the style.php cached css are not actually beneficial, php load_file_contents is terribly slow and orders slower than static pages. I think it't also not compressed when cached If i remember correctly.

So lots of optimization possible, it will only get better.

[ccagle8]

i agree that a point release is due... i plan on having one ready soon, but i would appreciate it if you guys could help with some of the development of these bugs. I would be forever grateful...

[Carlos]

Also it only detect new plugins if filecount changes, so dont rename or remove and add plugins at the same time, this should be a file collection md5 or something instead.

I would like to see this changed...

Do you think it would be enough checking if any plugin filename has been added or removed?

I intended to prepare and suggest a patch for function create_pluginsxml(), my idea was reading all *.php filenames in the plugins folder to an array and compare with $live_plugins's keys using array_diff() ... (BTW I also think the function can be optimized a bit, so that it doesn't even generate the xml data if it's not going to be written to disk.)

[ccagle8]

Great Carlos. Speed & efficiency is something i think that sets GS apart. Anything to improve speed is a plus.

Also, just so you guys know, the 3.2 or 4.0 (whichever is may be) roadmap will start being discussed shortly - id love for you three to help nail down the updates. You all have great ideas and really care about the project - so i want you all to have a huge say in the future of GS.

[Carlos]

On the plugins issue, one more comment. Another possibility (that I was thinking to suggest for 3.2) is doing like WP: plugins must be activated in the backend, or else they're not loaded in the frontend.
It would simplify this: the plugins.xml file would only be rewritten when in admin>plugins.

Also, just so you guys know, the 3.2 or 4.0 (whichever is may be) roadmap will start being discussed shortly

I suggest you release 3.1.1, 3.1.2, ... to fix all known issues (including the menu manager) before starting with 3.2.

Another suggestion: copy 3.1.x to another branch in the svn. The current branch would be now 3.2 beta.
If some -important- new issue is found later, you do the fix in both and release a 3.1.(x+1) for easy upgrade.
This separation would better be done when current known issues are fixed, so that you don't have to do double work for the svn.

(I imagine that mantaining 2 versions is too much work for this small dev team, that's why I haven't suggested this before.)

[shawn_a]

For the "plugins dir changed" I would just take a array of files and their sizes, sort it, serialize it, and md5 it.
Then just recompare the md5s every time you reload plugins.
Shouldn't be to expensive.

[Carlos]

For the "plugins dir changed" I would just take a array of files and their sizes, sort it, serialize it, and md5 it.

IMO we don't need the file sizes... It doesn't matter if some plugin has changed its size, does it?

[ccagle8]

I suggest you release 3.1.1, 3.1.2, ... to fix all known issues (including the menu manager) before starting with 3.2.

This will be the case... i was just talking about the two different releases at once. Sorry im confusing. Im writing this at work, so i try to keep my answers short and quick.

Do either of you guys want Commit ability? I trust both of you with our code since you both understand the core values of GS and have always looked out for it's best interests. I would love to get a few more coders on board other than Mike and I (and to a lesser extent Joshas).

[shawn_a]

For the "plugins dir changed" I would just take a array of files and their sizes, sort it, serialize it, and md5 it.

IMO we don't need the file sizes... It doesn't matter if some plugin has changed its size, does it?

True, I supposed it doesn't unless you wanted to cache something.

[Carlos]

my idea was reading all *.php filenames in the plugins folder to an array and compare with $live_plugins's keys using array_diff() ... (BTW I also think the function can be optimized a bit, so that it doesn't even generate the xml data if it's not going to be written to disk.)

Well, here's the possible patch. The xml data will only be generated and written to the plugins.xml file if any .php file has been added, removed or renamed (or if a plugin is activated/deactivated in admin>Plugins)

Replace whole function create_pluginsxml() in plugin_functions.php with:

Code:

function create_pluginsxml($force=false){
  global $live_plugins;  
  if (file_exists(GSPLUGINPATH)){
    $pluginfiles = getFiles(GSPLUGINPATH);
  }
  $phpfiles = array();
  foreach ($pluginfiles as $fi) {
    if (lowercase(pathinfo($fi, PATHINFO_EXTENSION))=='php') {
      $phpfiles[] = $fi;
    }
  }
  if (!$force) {
    $livekeys = array_keys($live_plugins);
    if (count(array_diff($livekeys, $phpfiles))>0 || count(array_diff($phpfiles, $livekeys))>0) {
      $force = true;
    }
  }
  if ($force) {
    $xml = @new SimpleXMLExtended('<?xml version="1.0" encoding="UTF-8"?><channel></channel>');
    foreach ($phpfiles as $fi) {
      $plugins = $xml->addChild('item');  
      $p_note = $plugins->addChild('plugin');
      $p_note->addCData($fi);
      $p_note = $plugins->addChild('enabled');
      if (isset($live_plugins[(string)$fi])){
        $p_note->addCData($live_plugins[(string)$fi]);    
      } else {
         $p_note->addCData('true');
      }
    }
    XMLsave($xml, GSDATAOTHERPATH."plugins.xml");
  }
  read_pluginsxml();
}

Please review and test before changing anything...

(Note that I have renamed a couple variables from the original function, $components and $c_note, I suppose Mike will agree...)

[Carlos]

Please someone check/test that modified function create_pluginsxml I posted...

[n00dles101]

Thanks Carlos, I'll check this out in the next hour or 2 ...

[Carlos]

Mike,

If you replace the function by the one I posted, you can also uncomment line 65 in plugin_functions.php -- it works better.

(As a reminder, all this should fix what @shawn_a reported: in 3.1 plugins.xml does not get updated if you rename a plugin file, or if you add one and remove other at once -- that is, if the number of plugin files doesn't change)

[shawn_a]

Mike,

If you replace the function by the one I posted, you can also uncomment line 65 in plugin_functions.php -- it works better.

(As a reminder, all this should fix what @shawn_a reported: in 3.1 plugins.xml does not get updated if you rename a plugin file, or if you add one and remove other at once -- that is, if the number of plugin files doesn't change)

I've been out of town, Il'l try to give this a test also. Nice solution, I didn't realize we already had a file array store.

[n00dles101]

@carlos, great work, all seems to be working fine.

I'll finish testing and upload to the SVN later today.