Wedge

(2 files, 2KB)

Revision: 1707
Author: arantor
Date: 24 September 2012 01:05:30
Message:
! SMF bug: if a subaction is declared in the admin menu and it is declared with a custom URL in the process, that will be ignored during the admin search processing all the menu contents. (Admin.php)

! Maintenance move boards in bulk had malformed tags, replaced the broken tags with the styling we're using elsewhere anyway. (ManageMaintenance.template.php)
----
Modified : /trunk/Sources/Admin.php
Modified : /trunk/Themes/default/ManageMaintenance.template.php

No, this was more of a 'this is what I think we could do' and wanting comments before I wrote it.Oh..... so you load the index file, pull the $txt entries out and inject that into the result file that then gets cached. Now it makes sense to me.

And now I understand the concern about language files and caching. There's one entire class of cases that's screwed up in passing - plugins. While we could check the core files for updates, and force those ones to be updated from the ACP, we can't do the same with plugins. There are no requirements about where plugins must keep their files, so unless we were to go through every folder of every active plugin, looking for .js files, just to look for @language directives, we can't do that.

The alternative is to simply nuke the cache when doing such an update and immediately rebuilding the most common (script, editor, topic) if affected and let the others rebuild on demand.I'm a stuck in the mud who uses one at a time mode, so it's very clear. I can post a screenshot if that'd help?

You're not too thorough with the three states. The reason I don't use notenice in the menu is simply because the green doesn't sit well in the menu when it's the active menu item. To replicate, make sure you have an unread PM that won't be marked read when you're on action=pm, then go to action=pm, so there's at least a (1) still present, and you'll see that green just doesn't sit nicely because of a lack of contrast. But it's more prominent on the menu.Then you started talking about @language also referring to multiple language files... which seems unnecessary to me.No, we don't. That's the underlying point of what I've been saying. If you have the files as-is and the database containing deltas, you do not need to worry about file dates, because you just cache it whenever the database changes. You don't need to keep rechecking - you tell people to use the language editor, which deals with all that stuff.

Hence all my comments about people that are stupid enough to edit the files.And if you know what files are changed you can safely just regenerate only the file that's changed, just when it's changed, job done.I'm thoroughly confused. Are you saying that you want to push the entirety of a language file into a JS construct so they can be used client side?

A language set is approximately half an MB. Even allowing for savings for language constructs being more compact, you're still talking hundreds of KB that almost entirely aren't necessary!

To be brutally honest, the number of strings actually needed and referred to solely in JS is actually surprisingly small, assuming it can actually be pushed to JS (because not all of them can, for example, some of the strings used in the moderation filters area are added inline but the bulk of them won't be known until a DB query has been run)

Better would simply be to find all the strings that are actually needed from JS and make a single file out of those which can be included as standard along with script.js. Then you get to simplify a lot of the architecture.It's completely unnecessary under everything I've been saying...

(2 files, 3KB)

Revision: 1704
Author: arantor
Date: 23 September 2012 18:59:36
Message:
! Use proper note classes for the numbers within the PM menu area. Everywhere else does it, this should too. (PersonalMessage.php)

! The manage rules area needed some consistency attached to it, using buttons consistently rather than two links and a button. Some minor logic changes were needed to make it work but no biggie. (PersonalMessage.php, PersonalMessage.template.php)
----
Modified : /trunk/Sources/PersonalMessage.php
Modified : /trunk/Themes/default/PersonalMessage.template.php

(Yes, a purely aesthetic commit from me. It doesn't happen often, either.)

Then I'll fix that first. I am aware there are cases of concatenation in the language files for the purpose of encoding line-endings into certain strings. This is standard practice for the editor and it is already actually aware of this. But I'll check for any other cases and fix it.I count 9 JS files at present: admin, captcha, editor, mediadmin, register, script, script-sha1, suggest, topic. That's not necessarily definitive, but what I've encountered so far in general use.Oh, it makes sense, but I'm not seeing that as a problem, actually.

add_js_file would load the file, you'd be calling loadLanguage or loadPluginLanguage anyway from there. That means, basically, you'll still fall into the process I'm talking about. There's no reason why the same process couldn't also contain the JS language file, though if I understand you correctly, you're almost talking about having multiple language JS files too...

Either way, I see no reason why an editor couldn't cope with being able to edit either and load from the DB, caching the results. It only has to worry about caching if people are daft enough to edit files directly, but then all bets are off anyway.

No, the message index has differently coloured columns, not differently coloured rows - just like Curve...

(1 file, 1KB - one line)

Revision: 51
Author: arantor
Date: 22 September 2012 16:29:39
Message:
! Updated birthday plugin with tweaks for scheduled task handling. In case it wasn't obvious, now it's the same as you'd pass to loadPluginSource (probably because that's what the scheduled task handler does too!)
----
Modified : /birthday/plugin-info.xml

(3 files, 7KB)

Revision: 1702
Author: arantor
Date: 22 September 2012 16:02:20
Message:
! Cleaner behaviour with respect to scheduled tasks in the event of a task being disabled, or if the installation moves folders/servers, by using the master folder listing rather than having the path in the DB. (ScheduledTasks.php, ManagePlugins.php)

! When disabling a plugin, check for any plugins that rely on the current plugin's hooks and refuse to disable it if any dependent plugins are found. (ManagePlugins.php, ManagePlugins language file)
----
Modified : /trunk/Sources/ManagePlugins.php
Modified : /trunk/Sources/ScheduledTasks.php
Modified : /trunk/Themes/default/languages/ManagePlugins.english.php


For the first case, this should not be any problem for any current Wedge user. The only time there is an issue is if a plugin has declared a scheduled task - to the best of my knowledge, there are only two plugins that currently declare a scheduled task, and neither of them are in use anywhere (Birthdays, WedgeDesk). It does also mean that when declaring the filename in the plugin-info.xml file you no longer have to prefix it with $plugindir. I will commit the update to the Birthdays plugin for reference later.

For the second, there are still going to be fringe cases. If you were to enable, say, Dragooon's notification plugin and the notify-on-reply child plugin, you cannot safely disable notifications without disabling the child plugin. Now the manager will not let you disable the main plugin without disabling the child plugin first. You could, theoretically, still disable it by physically altering the folder, but to remedy that would require a vast extra overhead every single page, to check all plugins every page, which is unnecessary.