Wedge
Public area => The Pub => Plugins => Topic started by: Dragooon on March 11th, 2013, 03:44 PM
-
There should be the ability to hook into e-mail templates, I'd like to use the existing interface and give the user an option to change language strings as they please. Seems like a neat idea.
-
Remember where I said about plugins being able to extend the language files? The exact same process would apply ;)
Though yes there needs to be a hook to extend the actual definitions too.
-
Remember where I said about plugins being able to extend the language files? The exact same process would apply ;)
Though yes there needs to be a hook to extend the actual definitions too.
I can declare new e-mail templates no problem, I need the hook to actually define them in the UI so that the user can edit.
-
There are two issues that result.
Firstly, loadEmailTemplate won't load your plugin's language file though you can do that yourself before calling.
Secondly, this gets tricky because the main language editor won't know to exclude your plugin's language entry and will attempt to load it anyway, meaning it would be editable from the main language editor rather than the email templates area. (Or it will when I finish it :P)
What this might mean is that I add the option to splice an existing plugin's language file into the DB, and reuse that option to exclude the same language file from the plugin area of the language editor.
-
There are a couple of things, the e-mail template shows a better UI for e-mails simply because of the replacement documentation, secondly all e-mail stuff is better at one place. Plus, perhaps you can exclude any language string defined as an e-mail template? That'll be easier than to splice it into the DB and having to define all the templates.
-
Well, it's more complex than that because generally you'd have a single file for email templates within a plugin (keeping them all together), and you'd want to exclude that from the list that the language area generates - which includes all files with the filename.language.php setup in every folder of every active plugin (it's good like that)
But unless you tell the language editor about the file it's still going to include it, even if it turns out there are no usable language strings there if that makes sense.
The splice-into-DB still needs to be done, IMO, for strings that would like to be available very commonly (e.g. that would like to be part of index)
-
I see, well I'll wait for you to implement a good solution. E-mail thing is way off into my list anyway.
-
That's the great thing about having this caching mechanism, it allows me to explore all kinds of craziness like this ^_^