Wedge

Yeah, I knew about that, but I wasn't sure if I could actually pay myself even in the sandbox. Since there's no harm in trying... I might as well try it!

It will also let me try out a few other things that need to be experimented with, namely looking into the bug that apparently exists with failed subscription transactions that happen for no apparent reason.

Also, the installation is currently completed broken. Moving that if() test around in Settings.php breaks the installer, because the installer now repeatedly and consistently removes the if() and the opening { of that test.

I'll fix it sometime, but I'm deep into other stuff first.

And on a fresh install, it always seems to me that jQuery can't be loaded from Google. This has never once worked for me on any test install I've ever made, including localhost.

Also, I have no idea how the sandbox works, especially since it doesn't seem to handle subscription payments. It seems to be geared for much larger and more complex stuff that we're trying to do.

After struggling along with the banality of the Sandbox, it's broken. It just tells me the address for entering PayPal was wrong, but it also flags the code before my change as wrong, which suggests sandbox mode is actually broken anyway.

It sort of IS up to me :P I sort of need to go through all of it mentally, so let's recap the whole thing end to end.

Ideally, I don't want anything in the DB that doesn't need to be there. The DB at a minimum needs to be able to contain what is different from the physical files, which means the DB needs to store enough to be able to work that out - which means, I guess: theme id, language file root, language of string, changed string. (Perhaps an additional column to indicate it is an array and should be unserialized on reading)

Then it's queried as necessary from loadLanguage.

From a cache perspective, we will likely need to recache language files, and to that end, I'm thinking we'll end up playing cache using the theme id, plus the language root, plus language - essentially caching something like '1-index-english' as the resultant content of that language file.

To me it seems that JS caching only needs to call on that combination (theme + language root + language) to find the file and then you have far fewer combinations. Clearing the cache when editing strings means the language cache, then the JS cache will be rebuilt. There should be no circumstance where files are edited manually and if users do do something stupid like that, it's going to be their own fault that it doesn't work properly. You don't have to worry about users that don't follow instructions - because they won't actively break anything by editing strings, it just won't propagate their changes.

That's for the worst case scenario of having multiple themes where the theme will also have to provide language strings itself, and we have to be able to make a distinction between two themes for the purposes of language files. It means you get a set of JS files per language per theme.

I'm just not seeing the need to store any cache values, unless there's something I'm missing...

Well, there's one very large problem to contend with: what happens if a theme (not a skin) decides to have its own language files?

There are all sorts of funky things tangled in the bowels of the code, such as the fact that themes can also have other themes as a dependent (so you can create one theme with a bunch of new code, and then create several full themes that depend on *that* theme)

I can fully see cases where people might push out their own actual theme, with their own templates and their own strings. For example, most of DzinerStudio's themes have a different board index layout to the standard, which also requires additional strings. Which can also be edited and will require caching.

Though I'm tempted to remove base_theme support, I don't believe anyone except Bloc ever used it and even then I'm not entirely sure about that. But I don't see that we can remove actual support for alternate themes in general.

But that makes caching potentially complicated, especially if people can choose between different themes as such, because even the JS caches might be different - if a theme declares its own index.english.php (which it is perfectly entitled to do) or replace any strings from index within its own ThemeStrings language file, that will need to be factored in, which means potentially you need to include the theme id in the cached filename.

No, the indicator is deliberately designed to be shown regardless - to let people know it's solved even if they can't mark it solved themselves.

(It's in the plugins repo... :whistle:)

Committed in r1712.

It's been grand getting back into the swing of things :)

Oh, I already did that. But there's a technical reason it's been done that way in the past - the point of pseudo buttons isn't really about new windows, but the fact that there's already a submit button inside the form that's involved, typically a delete button. Often that submit button belongs to a form that does processing, but where the link would go is a separate piece of code, which means far larger changes than just the HTML.