Wedge

[Commit revision 76d76c0]
Author: Nao
Date: Mon, 29 Dec 2014 12:54:44 +0100
Stats: 1 file changed; +1 (insertion), -3 (deletions)

• Subs-Admin is no longer needed in a function, the call was forgotten by Arantor when he removed some other code 2 years ago. (Errors.php)

---

[Commit revision 1b5c546]
Author: Nao
Date: Mon, 29 Dec 2014 20:42:50 +0100
Stats: 10 files changed; +150 (insertions), -141 (deletions)

• Renamed Subs-MinifyPHP to Subs-CachePHP, because now it does more than just minify a file. It also deals with everything a PHP file needs to go through to end up in the cache folder, including modding. (Subs-CachePHP.php)
• Moved updateSettingsFile() from Subs-Admin to Subs-CachePHP, to prevent any potential crashes if Subs-Admin was modified by a plugin mod and then another mod crashed another file. It's too complicated, just trust me on this one... Also, since it handles writing PHP files, it's similar in spirit to the other functions in that file. (Subs-Admin.php, Subs-CachePHP.php, ...)
• updateSettingsFile() will now determine variable types by itself, so there's no need to escape them before sending them to the function. That was one silly way of doing things..!
• Allowed loading Subs-CachePHP through loadSource, for convenience in calling updateSettingsFile; this doesn't change the fact that it's not moddable! (index.php)
• Renamed $settings['enabled_plugins'] to $my_plugins, to make the array independent from database access, allowing for more source files to be modded.
• Files modified by this commit: Subs-MinifyPHP.php, Load.php, ManagePlugins.php, ManageServer.php, ManageSettings.php, OriginalFiles.php, Subs-Admin.php, Subs-Plugins.php, Upgrade.php and index.php. I'm not listing them individually above because most of the entries would list most of the files anyway.

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

[Commit revision 5483d62]
Author:
Date: Tue, 23 Dec 2014 23:19:13 +0100
Stats: 1 file changed; +6 (insertions), -3 (deletions)

• Wedge didnt clean the html cache, so template modifications didnt get
• applied.
• If the plugin has no mods.xml we dont need to clean the cache at all.

---

[Commit revision 9d5de43]
Author: Nao
Date: Wed, 24 Dec 2014 00:34:13 +0100
Stats: 1 file changed; +6 (insertions), -3 (deletions)

• Merge pull request #24 from C3realGuy/master
• Wedge didnt clean the html cache, so template modifications didnt get

[Commit revision f73826a]
Author: Nao
Date: Mon, 22 Dec 2014 00:59:22 +0100
Stats: 3 files changed; +3 (insertions), -3 (deletions)

• Unused globals. (Security.php, Subs-Cache.php)
• HTML tags aren't allowed in error messages... (Subs-MinifyPHP.php)

[Commit revision 921070e]
Author: Nao
Date: Sun, 21 Dec 2014 20:54:56 +0100
Stats: 4 files changed; +0 (insertion), -5 (deletions)

• Removing disableTemplateEval setting... Next commits will deal with the feature in a way that allows running evals without losing any time. Permission to look smug, sir? (ManageServer.php, Help.english.php, ManageSettings.english.php, install.sql)

Or maybe they fixed the original bug for which I wrote a workaround.
I think it's in topic.js, try to find the is_firefox test and remove it... Dunno. I think that's a possibility.

:edit:

So... I read that it was possible to fix this by clicking 'Reset Firefox'... Which I did. It proceeded to create a new profile for me. Okay, right... I've lost everything. Add-ons, tabs, etc. No problem, I'll just re-enable the old profile. And guess what..? That stupid feature removed the old profile as well!! The entire folder, including all of my manual backups!
WAY TO GO AGAIN, FIREFOX!

I'm hereby pledging that I will NEVER again use Firefox as my browser. Just like Internet Explorer, it will now be relegated to "stupid browser that I have to provide REASONABLE support for, meaning I'll try to run it once a year and see if it doesn't break everything Chrome and Opera render correctly..."

Man, I'm pissed! I lost something like 600 tabs in the process!! And because their profiles are stored in the main Windows drive, I couldn't even manually recover my old files with Recuva. I only managed to recover a 2013 session, yay, good for me... -_- One year of new tabs lost -- and one year of old tab cleanup, too. And of course Firefox 35 won't load this session anyway, I'm just stuck with an old JSON file that I'll have to manually cruise through to get my tab list, or I'll have to downgrade Firefox, I don't know... Still, great.

Phew... I guess I'm not done yet; it simply moved the profile to a new folder on my desktop. (I never use the desktop; I only read this on their troubleshooting pages.)

Guess I'll try and downgrade, now...

Phew... Fixed. I had to downgrade to v32, and then I was able to restore my old session. Good.

Now I just need to find a way to have both v32 and the latest version running around, with different profiles for each... :-/