Wedge

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 ;)

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 ^^

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:

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!

(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.)

Does this mean that every used and installed plugin has to been modified.......non of the installed plugins are working at this moment.

All old plugins should still work. This just gives a lot more possibilities to plugin devs.

Not one of them is working...when i clicked to actived them.

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).

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!

Thanks that was the issue........plugins up and running .