Wedge

I should add, after my experimentation in recent times on a shared host, I'm strongly motivated to set this hard-core caching to off (leave parsing etc. running, but not gzipping the files on the server by default)

It was not a particularly exciting test run to start with.

No longer an issue, though create_button has been mutated today, heh.

Bumping to put this nearer the top of my todo list. Any idea how short the meta description should be?

And it's much nicer now. Or it will be when it's committed. I ripped out the secondary layer of arrays, plus all the random documentation blocks and it's looking much friendlier (bad news: there's an extra line of language per email template as the one-line description, sorry about that)

But that's sort of the point of this feature - so that people who want to customise it never have to touch the file manually.Removing it is easy enough. Switching over, not so much. I couldn't find out with any reliability what the Skype user name would be or what the rules are, or for that matter what to put as the link (with any reliability) so it sort of fizzled out on that score.

So I'm working on a new feature and as ever this means new UI, and I suck at UI.

But here's the WIP as it stands. I'm sure you'll have no difficulty guessing what feature this is (first picture is older than second, it's still evolving and nothing is set yet)

Most FTP clients seem to use current system date when uploading...Hmm.Then break it down and deal with it in stages. Especially with optimisation. Do that last.Use what looks best. Something that's a few bytes more but looks better would be better appreciated by the users.The very right would be better. I don't know that it would be 'much' shorter. But it's where it should go, IMO.Yeah, that sort of thing sucks :( This is why I don't do optimisation until late in the day, if at all. I tend to hammer it out, iterate it, fix the bugs in it and then (and only then) worry about making it smaller. Like the change in r1930 about fixing the ternary, IIRC there wasn't even that if to start with, it only came about as a bugfix, and even though there's currently a missing space by the :, I would personally have been happy with it how it was - ternaries make it smaller, yes, but they do make it harder to follow again later :/ It's all good, though.

Everything still seems to work with respect to number_context anyway ;)

OK, here's the deal. We have a mostly functional language editor in the admin panel. But it relies on directly editing language files which is a bad idea, not just from a security standpoint but it's not entirely survivable through upgrades and so on.

For months I've wanted to replace it with it being held in the DB, so that users can change it with impunity, without having to worry about the language files being changed in permissions. It's friendlier to the user too. (Or at least it will be once I finish the rest of it.)I rarely, if ever, do anything primarily for performance. Performance is not my greatest concern, if I'm honest. This one is primarily a usability/security feature. The caching changes are to preserve existing performance without compromising the benefits of having the language changes table, since the hit of having another query every call to loadLanguage would be huge. Or even another query per page (to scoop up everything) wouldn't be much better.

The caching is to prevent DB queries, not to deal with perceived slowdowns of loading files. From a straight performance standpoint, once a cache file is actually built it should be near enough the same performance as loading language files was before. There is some slight overhead for a given file, but that's offset by the fact that it will invariably be only checking for one file and rebuilding the cache if it does not exist.

Already there is an advantage of this - the new registration agreement area, which no longer requires changing agreement.txt (or agreement_french.txt as was, which also had side issues potentially related to incorrect encodings) is now fully editable from the admin panel without having to navigate FTP permissions.Oh yes. This is a means to an end, not an end in itself. Consider the updated registration agreement page. While that was technically possible before (the editor aspect), the file permissions part wasn't.

It also simplifies language pack distribution too by only having one folder to put everything in.No, it doesn't.

When, exactly, is the admin going to upload new language files? I will say it again: if they're going to manually mess with the files, that's their lookout. There will be no need for them to mess with the files directly as there will be a better interface available from the ACP which will deal with the caching aspect itself.Well, if it's suitable from your perspective, it just needs to preparsecode'd (or do as I did, post it into a post, then copy the content back out the DB after) and put into Agreement.french.php.I didn't add a key on it (and yes, it was the custom fields table) because I couldn't validate that adding an index would make it any faster. The field is simply for ordering the entries of custom fields. A certain amount of that is cached elsewhere inside the core anyway meaning that adding an index is almost counter productive.

(11 modified, 1 removed, 18KB)

Revision: 1929
Author: arantor
Date: 18 February 2013 18:15:56
Message:
! Updated installer SQL with correct primary key. (install.sql)

! Don't show the warning status about bans to a given user if they themselves are softbanned. (Load.php)

! Bug fix - after the debug strings were moved to Stats lang file, the query viewer got upset. (ViewQuery.php)

+ First commit of magic new language entry cache thingy. NOTE: Language files are cached now. If you change a language file remember to dump the relevant cache of it. This is only for developers; regular users will be able to use the admin panel in future to do this. (Load.php)

! Registration code now uses the proper language string entry. (Register.php)

+ Manage registration now has spiffy new interface that interacts with the DB to update things. Juggled a few things about, gave it proper editing facilities. (ManageRegistration.php, Register.template.php, Admin language file)

! Some subsidiary stuff: don't let the current language file editor touch the agreement file and strip remaining entries of agreement.txt. (ManageServer.php, Packages.php, upgrade.php)

- Don't need scratty old agreement file any more. (agreement.txt)
----
Modified : /trunk/Sources/Load.php
Modified : /trunk/Sources/ManageRegistration.php
Modified : /trunk/Sources/ManageServer.php
Modified : /trunk/Sources/Packages.php
Modified : /trunk/Sources/Register.php
Modified : /trunk/Sources/ViewQuery.php
Modified : /trunk/Themes/default/Register.template.php
Modified : /trunk/Themes/default/languages/Admin.english.php
Modified : /trunk/Themes/default/languages/Admin.french.php
Deleted : /trunk/agreement.txt
Modified : /trunk/other/upgrade.php
Modified : /trunk/root/install.sql


@ I can attach files. Why shouldn't I? It might get people to look in this topic more often? ;)