e107inc / e107-test

For developmental use with e107 v2.
2 stars 2 forks source link

Test issue or core issue? #9

Closed CaMer0n closed 5 years ago

CaMer0n commented 6 years ago

Sorry to disturb, but I've hit a bit of a wall and lost hours getting nowhere with this issue. :/ So, the e_plugin class (e107::getPlug()) was added as the beginning of a rewrite of the e107plugin class. (e107::getPlugin() ) Right now it handles mostly the meta data and e107_plugin db table information.

So, today I wrote some tests and tried adding this code below inside getPluginRecord():

if($tmp = e107::getPlug()->load($path)->getFields(true))
{
    return $tmp; 
}

It returns the same data as the DB table lookup below it, however it is causing almost all the plugin installation unit tests to fail due to missing prefs or prefs left behind after uninstall.

So, I'm not sure if this is some kind of pref cache issue specific to running the tests, or if it's a larger core issue or something else I haven't thought of.

save_addon_prefs() was also eventually meant to be replaced by e107::getPlug()->buildAddonPrefLists()

A similar issue occurs, if I return e107::getPlug()->buildAddonPrefLists() from inside save_addon_prefs.

If you update the main e107 repo, you'll see the commented-out code in these areas.

Any suggestions or ideas would be most welcome!!

Deltik commented 6 years ago

I've only just begun to look into this issue, but it is not true that the return value of e107::getPlug()->load($path)->getFields(true) (Candidate B) is the same as at the bottom of e107plugin::getPluginRecord() (Candidate A).

When installing, Candidate B returns an array where the keys plugin_installflag and plugin_id both have int type values. Candidate A has string type values for those keys.

When uninstalling, the same thing happens, but there is an additional difference: Candidate A returns a string value of "1" for plugin_installflag while Candidate B returns an int value of 0.

This means that Candidate A and Candidate B are not equivalent and probably breaks logic in some methods that call e107plugin::getPluginRecord(). These tests are affected:

screenshot_20180804_070222

CaMer0n commented 6 years ago

Thanks @Deltik ! I did notice that also, but changing the value type didn't appear to change anything in the outcome..

Here's what I get with plugin_installflag and plugin_id as 'string'.

image

Deltik commented 6 years ago

@CaMer0n: I don't think it has to do with the value type but rather the different value of plugin_installflag when uninstalling a plugin.

CaMer0n commented 6 years ago

@Deltik Thanks, will check it out.

Deltik commented 5 years ago

@CaMer0n: e107inc/e107#3532 fixes this issue.

CaMer0n commented 5 years ago

Excellent! Thank you!