Wedge

Public area => Bug reports => The Pub => Archived fixes => Topic started by: CerealGuy on December 26th, 2014, 10:05 PM

Title: FileModification before $context['enabled_plugins'] is set
Post by: CerealGuy on December 26th, 2014, 10:05 PM
Currently you cant modify Files like Class-System,QueryString,Subs,Errors,Load etc. because $context['enabled_plugins'] isnt inited yet. Perhaps that should be done before loadSource ever got called?!
Title: Re: FileModification before $context['enabled_plugins'] is set
Post by: Nao on December 26th, 2014, 11:31 PM
I tried to find a solution for this earlier but was a bit stumped. The query problem is solved by only initializing it when an uncached file is to be loaded. And testing for isset rather than !empty.
Other than that, I'm all ears...

Sorry, was in my family for Christmas, just got back, gimme some extra time ;)
Title: Re: FileModification before $context['enabled_plugins'] is set
Post by: CerealGuy on December 27th, 2014, 12:27 AM
I went threw different "solutions" for this but didnt find one with which i was really happy ^^.
The one which I like the most in the moment needs a bit more to change, but it would reduce some I/O tasks. But here some ideas:
1) I would get enabled_plugins always via sql, no need for cached settings, but move it in an own table. We could also build this sql query without Class-DB so no need for a loadSource or a require (dont really like this but how else could you load Class-DB without any "depend" problems?!).
2) When going through those plugins we could already check if any of them has mods.xml and if yes which files are interesting. With this information we dont need to open mods.xml for every plugin when calling apply_plugin_mods.
3) Create a global $mods array which knows which plugin modifies which file. apply_plugin_mods would not need to know enabled_plugins anymore. $mods['pluginpath'] = array('pluginname', array(file1, file2...)). And if $mods is empty, apply_plugin_mods can return.

Just some quick ideas, perhaps its just brainshit, its already late i think :D
And i think this should be in bugs, dont know why the hell i opened this thread under plugins :hmm:.

Hope you had some good time with your family? For me its always a bit stressful, and too much food ^^
Title: Re: FileModification before $context['enabled_plugins'] is set
Post by: Nao on December 28th, 2014, 11:34 AM
First of all, I'm not going to do some magic trick with Class-DB, if I need data before the database is available, then I'll use Settings.php (updateSettingsFile) to store it, rather than updateSettings...

Now, what should we store in the file...? enabled_plugins is a given... But I could also store a list of files that are to be modified by plugins. That's what I'm considering right now, but it might also be overkill... Remember, caching is to be done on all files when the cache is purged, but (1) once they're cached, files remain cached until you explicitly uncache or change plugin statuses, so it'll only slow down a few page loads and then the rest won't bother, (2) I don't know if it's worth loading a list of those modifiable files on every page load, when as I just said, it'll only be used once in a blue moon...

So, for now, I'll focus on just moving enabled_plugins to the settings file! ;)
Title: Re: FileModification before $context['enabled_plugins'] is set
Post by: Nao on December 28th, 2014, 12:01 PM
Okay, from this on, I have two possibilities for the $enabled_plugins variable...

1- Either I store all enabled plugins into Settings.php,
2- Or I only store enabled plugins with a mods.xml file into Settings.php (under a different name, like $enabled_mods), and I store the rest into $settings['enabled_plugins'].

1 takes more space in Settings.php and requires doing an extra file_exists() per plugin, but 2 requires disabling & re-enabling a plugin if it's currently enabled and you manually add a mods.xml file to it.
What would be best..? Would most plugins provide a mods.xml file anyway, in which case I might as well use the first solution... Currently, obviously most plugins don't use a mods.xml file, but as this technique was added to encourage developers to port their SMF mods to Wedge (and be satisfied that they'll meet less inter-plugin compatibility issues than with SMF), I can envision that eventually, most plugins will have file mods as well... So, solution 1 is what I'll be using if nothing else comes up.
Title: Re: FileModification before $context['enabled_plugins'] is set
Post by: CerealGuy on December 28th, 2014, 12:28 PM
I vote for the first because as an administrator you have a bit more control about it (you could also rename the plugin, but Settings.php is also a nice way to modify it quickly) and in general its more clear if you look at Settings.php and see all enables plugins and not just some of them. Think about someone who edits Settings.php and wonders why there are only some of his enabled plugins. Also the file_exists thing doesnt need that much time that you have to care about it, plus its more fail resistant.

Interesting way to solve the problem, i like it :cool:
Title: Re: FileModification before $context['enabled_plugins'] is set
Post by: Nao on December 29th, 2014, 08:49 PM
I don't have much time to do testing, but the latest commit, which is relatively huge compared to most of my recent work, seems to be working.

A few things were renamed, updateSettingsFile no longer works as it used to so you'll have to adapt plugins that make use of it, but other than that, it's better than before. And it accepts most files to cache :)

I'm counting on you to test this in particular, @CerealGuy!
Posted: December 29th, 2014, 08:45 PM

(Now, all that's left to do is do the same for JS scripts and CSS files... LOL! It's doable, yeah, don't worry about that.)
Title: Re: FileModification before $context['enabled_plugins'] is set
Post by: CerealGuy on December 30th, 2014, 12:30 PM
Looks like you missed to change the require in Subs-Template.php
Line 1129
require_once(APP_DIR . '/Subs-MinifyPHP.php');

In the moment i dont have much time, but theres something wrong in apply_plugin_mods.
Code: [Select]
// Phase 1: Waste no time if no plugins are enabled.
if (empty($my_plugins) && empty($settings['enabled_plugins']))
return;

if (empty($my_plugins))
$my_plugins = $settings['enabled_plugins'];

$this_file = $error = false;
foreach ($context['enabled_plugins'] as $plugin)

foreach loop uses $context, but i think you want to use $my_plugins. Also it generates an error, which wedge isnt able to catch. But my errror.log says "PHP message: PHP Warning:  Invalid argument supplied for foreach() in /usr/share/nginx/www/wedge/core/app/Subs-CachePHP.php on line 189
". Also my_plugins is a string, so some split is needed.
Title: Re: FileModification before $context['enabled_plugins'] is set
Post by: CerealGuy on December 30th, 2014, 05:34 PM
Everything's now working, awesome :cool:.
Thank you so much @Nao, i totally love wedge :D
Title: Re: FileModification before $context['enabled_plugins'] is set
Post by: Jurien on December 30th, 2014, 05:39 PM
Does this mean that every used and installed plugin has to been modified.......non of the installed plugins are working at this moment.
Title: Re: FileModification before $context['enabled_plugins'] is set
Post by: CerealGuy on December 30th, 2014, 05:41 PM
All old plugins should still work. This just gives a lot more possibilities to plugin devs.
Title: Re: FileModification before $context['enabled_plugins'] is set
Post by: Jurien on December 30th, 2014, 05:49 PM
Not one of them is working...when i clicked to actived them.
Title: Re: FileModification before $context['enabled_plugins'] is set
Post by: CerealGuy on December 30th, 2014, 06:04 PM
It looks like you have some problems with your file permissions. The user under which your httpserver is running (or on which php is executed) needs to has rights to write to Settings.php. Until now this wasnt needed, but now it is. If you have a webspace, just change the filepermissions with your ftp client to 755 (or maybe 777 depends on your webspace).
Title: Re: FileModification before $context['enabled_plugins'] is set
Post by: Nao on December 30th, 2014, 07:20 PM
Also make sure to purge the cache just in case.

Which makes me realize I forgot to force purge CSS and js files where I'm force purging HTML files... Oops! I'll deal with that later. In the meantime, purge manually!
Title: Re: FileModification before $context['enabled_plugins'] is set
Post by: Jurien on December 30th, 2014, 08:33 PM
Quote from CerealGuy on December 30th, 2014, 06:04 PM
It looks like you have some problems with your file permissions. The user under which your httpserver is running (or on which php is executed) needs to has rights to write to Settings.php. Until now this wasnt needed, but now it is. If you have a webspace, just change the filepermissions with your ftp client to 755 (or maybe 777 depends on your webspace).
Thanks that was the issue........plugins up and running .
Title: Re: FileModification before $context['enabled_plugins'] is set
Post by: Nao on December 30th, 2014, 10:10 PM
This shouldn't happen BTW.. Settings.php is created by Wedge itself, so you should have the rights to it...

Unless you installed it before my rewrite a few months ago... Dunno.
Title: Re: FileModification before $context['enabled_plugins'] is set
Post by: Jurien on December 30th, 2014, 11:21 PM
Quote from Nao on December 30th, 2014, 10:10 PM
Unless you installed it before my rewrite a few months ago... Dunno.
About 2 months ago,converting database Smf to Wedge database using the importer tool.
Title: Re: FileModification before $context['enabled_plugins'] is set
Post by: Nao on December 31st, 2014, 10:40 PM
If it's imported, wedge might inherit the SMF file permissions indeed. In which case you were never able to change some admin settings for SMF either...
Title: Re: FileModification before $context['enabled_plugins'] is set
Post by: Jurien on January 1st, 2015, 11:21 AM
Quote from Nao on December 31st, 2014, 10:40 PM
In which case you were never able to change some admin settings for SMF either...
No I never had any problems with it