Forgot your username?             Forgot your password?

You need to be a subscriber in order to receive support. If you want to report a bug or ask a pre-sales question, you don't have to be a subscriber. Just use the Contact Us link at the footer of the site.

Subscribe

#11939 – Request for connecting emails to subscriptions

Posted in ‘Akeeba Subscriptions !! SUPPORT FOR THIS COMPONENT HAS BEEN TERMINATED !!’
This is a public ticket. Everybody will be able to see its contents. Do not include usernames, passwords or any other sensitive information.
Tuesday, 10 April 2012 18:30 CDT
zebrafilm
JOOMLADELUXE, SOLOPHP
Dear Nicholas,

I have to come back to this issue because my clients need my help all the time to setup their email messages to their clients/subscribers..
You have organized them in plugins/language files, meaning they can only be very generic.
My clients want to send a introduction email to the client with different content for different levels.

They really need to be able to input it in the backend instead of fiddling around with FTP in .INI files.
Why not add an email message section after the already existing form for a website message?

Preferable a space for a message and the option to add an attachment.I understand you haven't implemented a language system but if it works like the website message I am already happy.

Please consider this.

Bastiaan

Wednesday, 11 April 2012 06:57 CDT
nicholas
SOLOPHP, BACKUPWP, AKEEBASUBS, JOOMLADELUXE
Well, if someone wants to contribute code towards that feature, here is the feature list that it must fulfil in order to be better than the current translation string system:
- Allow users to enter per-subscription level, per-language, per-event email text without confusing the user (a dozen events, two of languages and five subscription levels would result in one hundred and twenty translation strings - imagine that on a single page, each rendered as an editor area!)
- It works in the plugin configuration page (i.e. this configuration interface is not hard-coded into the component itself) <-- This is the most difficult contraint of them all!
- Does not require hacking the Joomla! core.
- Does not require a new database table (if it does I might still accept the solution)
- It doesn't rely on mooTools (because it changes on every Joomla! version and can't be relied upon for a long term solution)
- It will automagically update the default text per language and action if it is updated and the user has not modified it, or it will allow the user to skip entering text for the translation strings he/she doesn't want to customise.
- Will guess if the user is entering plain text or HTML and in the latter case will figure out if the HTML entered by the user is compatible with the subset of HTML displayed by mail applications and webmail environments.
- Apply all the necessary changes to the email plugins so that they support this new configuration approach.

If someone pulls this impossible feat, I will include his patch into Akeeba Subscriptions and hire him as my new senior developer the very next second ;)
Sunday, 15 April 2012 02:15 CDT
zebrafilm
JOOMLADELUXE, SOLOPHP
Hi Nicholas, thanks for the extensive answer. I am sure you thought about it and made the current one the best balans between coding and usability.(especially for a free component)

On the other hand, this is still a geek solution, not one my clients can deal with.
If we forget about connecting them to an event and keeping them general:
Just another thought: would it be possible to create a TAG or something inside the message that points to a standard content page(ID)?
That way people don't have to dig into FTP and can enter some text in a simple way.
Message can contain multiple languages unless a TAG points to a category where the content has been appointed to different languages.

Bastiaan.
Sunday, 15 April 2012 06:09 CDT
nicholas
SOLOPHP, BACKUPWP, AKEEBASUBS, JOOMLADELUXE
Well, I did think about this very thoroughly. The problem is that when a security exception is raised, there should be a minimal amount of processing performed. Remember that in this case we just detected the Internet equivalent of someone firing a bullet at us. We are trying to dodge the bullet and minimise the inflicted damage. You are trying to use a gun as a doorbell; when someone shoots at your door you want to go answer it. This is not what Admin Tools was designed for.

The GeoBlock feature has the "block" thing in its name for a good reason: it's designed to block (stop) requests coming from forbidden countries / continents, within the accuracy constraints of an IP to country database. It's not called GeoForward because it was never intended to be used as a means to forward visitors to different sites based on their country of origin ;) If you don't like the workaround which would allow you to use the GeoBlock feature as a makeshift GeoForward feature, you most likely have to find a developer write you an end-user-friendly GeoForward component. Such a feature has no place in Admin Tools. Besides, I would never implement a feature which I tell you upfront that it's the wrong way to handle your problem.

If you google around, you may come up with a few alternatives. For example, there's this solution but, as the author says, it's dead slow and not recommended (and I agree with him). Or you can use MaxMind's own server-side Apache module to do that, but you need to compile it and have your server load it. Or you can use a 10$ plugin to do that. There are solutions out there. Just don't try to jam a round peg in a square hole just because you happen to have a lot of round pegs lying around :)
Sunday, 15 April 2012 06:18 CDT
zebrafilm
JOOMLADELUXE, SOLOPHP
Ahum.... I was talking about ASUBS......

Looking forward to hear you about security next weekend and hopefully not only focus on Apache....
If you need a place to stay in Amsterdam, just let me know.

Bastiaan
Sunday, 15 April 2012 06:31 CDT
nicholas
SOLOPHP, BACKUPWP, AKEEBASUBS, JOOMLADELUXE
Woops, I mixed your post with another one. Regarding the email translation files, your suggestion would not be possible. We'd still need a way to map each and every language to each and every action and figure out if there is an article or not, if it contains HTML or not, how to sanitise HTML (including CSS styles, linked media files etc) for inclusion in an email and so on and so on. When you get down to implementing it, you'll realise that:
a. the email messages only change three times: when you start implementing the project, after the first week you run the system and after a month you run the system. Then the text is pretty much left intact. Remember the context of this text: you just want to thank someone for registering and provide him with a couple of links where he may find more information. There's nothing stopping you from providing a link to a Joomla! category or article in the text (hint hint).
b. Trying to make the text customisable in the way you suggested results in such a complicated interface that people are appalled and ask you for something simpler. (yes, I've tried that with my own clients, that's how I ended up with INI files)

As I said, if someone finds the silver bullet and codes it, I'll happily include it in Akeeba Subscriptions.
Tuesday, 15 May 2012 18:00 CDT
system
This ticket has been automatically closed. All tickets which have been inactive for a long time are automatically closed. If you believe that this ticket was closed in error, please contact us.
This ticket is closed, therefore read-only. You can no longer reply to it. If you need to provide more information, please open a new ticket and mention this ticket's number.