dmm1 / newsletter Goto Github PK

I'd suggest to release (and tag) Newsletter version 3.0.0 soon.

Please note issues in this issue you want being solved before that.

Why 3.0.0: Since there were so much changes (+10000 lines, -10000 lines), we should introduce 3.0.0.

• Update pot file - done in #113
• fix #85 @dmm1
• standardize plugins

Before I spend more time in this, please to be confirmed from somebody, that this not working.

To test: copy html.tpl from
modules/Newsletter/templates/output directory
to
themes\MainSiteTheme\templates\modules\Newsletter\output

and make some changes to html.tpl. It seems changes have no effect over original file.

Imported from Thilo:

When Newsletter runs (I do it manually), the plugins fetch any content of the site, even access restricted Mediashare items, etc. I guess the plugins read my user Permissions (admin) when the Newsletter is created. I would like to propose that Newsletter (at least when it runs automatically) uses the Permissions of a freely definable user. The site admin could create a dummy user for this purpose, with the correct Permission assigned to.

One proposal looking at "Archive settings", It is possible first section to go in "Settings", and second "Prune Archives" can go at bottom in new "Newsletters" section.

Main recon is, because this menu is rare used, and admin links in the module menu are too much.

To solve this, I'd suggest:
Replace in PluginNewsArray.php:

$sort   = "$column[cr_date] DESC";

with:

$storyorder = ModUtil::getVar('News', 'storyorder');
switch ($storyorder)
{
    case 0:
        $sort = "$column[sid] DESC";
        break;
    case 2:
        $sort = "$column[weight] ASC";
        break;
    case 1:
    default:
        $sort = "$column[from] DESC";
}

See this: nmpetkov@c30c425#L0R51

check if e.g. a newsletter item was sended before or not:

imported from Rallek:

bug description

I have a site with low volume of news. But sometimes we have several in a week. If I sent out automatic newsletter monthly, the same news are sended every month, because no new news are created. I would expect, that the allready used news are not used again for the newsletter.
bug analysis

In the database it is not stored wich news are already sended
fix recommendation

no idea

I tested new realization for Automatic sending - after @cmfcmf removed maintenance block and replaced with pageLoad Lictener (#84). Here is what I found and my suggestions.

1. Listener works - that means on every page load it is checked if conditions to send newsletter exist. Listener executes doesn't matter what kind of user visit the site, and doesn't matter if auto--sending is turned on.
2. In listener if auto--sending is turned on - proceeds with further checking and eventually sending newsletter to proper users (it is really difficult to test if proper kind of newsletter is send to proper users - and at one moment I gave up!.

Suggestion:

• Please remove registration of this pageLoad listener in module instalation, but this to be option - if checkbox for auto-sending is turbed on, then this listener to be registered. Checking conditions on EVERY page load is not suitable for all kind of users!
• Also, if checkbox for auto sending turns off auto-sending - then pageLoad listener to be turned off (unregister).

NewsletterDataArray::getNewsletterData()

seems to be the problem:

/*
FIXME: Language management in gettext is quite different, have to process one execution per language now
if ($language) {
    include_once("modules/Newsletter/pnlang/$language/plugins.php");
} else {
    pnModLangLoad('Newsletter', 'plugins');
}

if ($enableML && !$language) {
    return LogUtil::registerError(__('Please use the language selector in the Filter section to select the language you with to send your newsletter for', $dom));
}
*/

In PluginNewsletterMessageArray.php around line 23:

$defaultLang = System::getVar ('language');

This returns legacy code (eng for example), and then is compared with standard code (en for example).
This leads not to load proper message, even is not loaded in case for default language.
If get proper code, for example with line:

$defaultLang = System::getVar('language_i18n', 'en');

In ZLanguage class I can't find proper method to get default language, so above proposal is using System::getVar.

I'd like to discuss some changes to database structure.

1. First of all I noticed table prefix still exist, and can be removed for next version.
2. In newsletter_users there is a field nlu_last_send_date, but it is also handy to have nlu_last_send_nlid, pointing to last sent newsletter from table newsletter_archives (if the case is such). Then can make a procedure, to send last archive to users. And re-send in case some emails are not sent for any reason.
3. In table newsletter_archives there is field nla_text, but more convinient is to have 3 fields:
   nla_html - for the HTML content for newsletter
   nla_text - for the plane text content for newsletter
   nla_textweb - for the plane text with web link to html
   Then, when sending archive to users, it is easy to get proper field.
   Upgrade is also easy, and is posible to move/copy past nla_text in proper column.

check if an e-mail adress is valid and spamcheck

I have tested the last days. All works fine except for autosend. I'm getting errors when a non-logged-in user causes an auto-send. I will investigate what's going on soon. After that we can release Newsletter 3.0.0

e.g. if a registered user changes his e-mail the subscribers e-mail should change also, if wanted.

It seems as if in all cases the Zikula email adress of registered users is used. You aren't able to change the email adress via the Subscribers page.

where most of the settings of the settings page are set. I would do that, but I don't know any module / example using the interactive installer.

I investigated some time to learn about html emails good practices, and all is going to move styles to inline. (Here is to extend discussion in #76).
Gmail is one important e-mail client, and test I have just made approves that he is ignoring style tags in head or body, but have respect to inline styles.
It is same with Gmail client for Android phones.

I have the LuMiCula editor activated for Clip. The Newsletter now gives that output in html.tpl:

Als Grundlage hierfür dient der ImageUploader ([url]http://github.com/lmm-git/ImageUploader[/url]), der extra dafür konzipiert ist, möglichst einfach eine Möglichkeit nur zum Bilder hochladen sowie einbinden zu bieten. Um mit diesem Bilder einzubinden, müssen Sie folgendes tun: [list] []Erstellen Sie ein neues Event, in dem Sie einen Wizard auswählen. []Wenn Sie bei der langen...

• As you can see, the LuMiCula filter hook ist not working (which is logically, because the Newsletter has no "notifyfilters" stuff).
• The truncation breaks the [list].

Imported from Lordevol:

It's a pity that only the automatic sent newsletters are stored in the database.
I send them manually, so they are not stored in the database and the "newsletter achieve" is empty :(

I suggest to store in the database the newsleters sent manually too.

Regards

I found these two files

• https://github.com/dmm1/Newsletter/blob/master/lib/Newsletter/DBObject/ExportArray.php
• https://github.com/dmm1/Newsletter/blob/master/lib/Newsletter/DBObject/ImportArray.php

It seems as if it is import and export functionality for subscribers via CSV and XML. But it is nowhere called and there is no button for it.

Maybe @dmm1 knows why there is no button and why it was removed.

In fact, Newsletter module scans the site for latest content.
It can be useful to build a function, very similar to "instant" newsletter, but to show to the user "What's new" in the site. It is very similar to Newsletter preview, but instead in preview window, result is shown in main content box for the site.

It is even possible then, Newsletter module to be used for this purpose only (if the site don't like to have newsletter).

Creating this issue as feature, just not to forgot for the future.

-) Various fixes needed, e.g. Newsletter_Util.class.php row 111 - fixed
-) during subscription the Language is not stored

It is very outdated and confusing.

I found this:

/*
FIXME: build the shortURLs correctly

public function encodeurl($args)
{
    // check we have the required input
    if (!isset($args['modname'])) {
        return LogUtil::registerArgsError();
    }

    if (isset($args['args']['ot'])) {
        return $args['modname'] . '/' . $args['args']['ot'];
    }

    return $args['modname'];
}

public function decodeurl($args)
{
    // check we actually have some vars to work with...
    if (!isset($args['vars'])) {
        return LogUtil::registerArgsError();
    }

    $args['vars'] = array_slice($args['vars'], 1);

    System::queryStringSetVar('func', 'main');

    if (isset($args['vars'][1])) {
        System::queryStringSetVar('ot', $args['vars'][1]);
    }

    return true;
}
*/

in UserApi. Any suggestions what that means?

1. Add possibility for other modules to provide a PluginModuleNameArray.php class Then these classes would be updated (if necessary) by the module authors and would not become deprecated.
2. Or maybe give the possibility for other modules to provide an API function like getNewsletter() returning the rendered Newsletter content.

All plugin classes are placed in DBObject directory and the name is like:
PluginNewsArray.php for the file, and
class Newsletter_DBObject_PluginNewsArray extends Newsletter_DBObject_PluginBaseArray
for the class, and
class Newsletter_DBObject_PluginBaseArray extends DBObjectArray

Before the upcoming module release, it is arising questions:

• Why to extend DBObjectArray (it seems will not be supported in future, and I'm not seeing any benefits to be so);
• If not inheritance from DBObjectArray, why not to be placed in other directory (it seems in future this directory will not be very good place for plugin classes).

What do you thing?

create a set of recipients groups (e.g. News / Clip ) and let the user select which info he wants e.g. news-articles from special category only or all...

Link "Archive" is not shown to unregistered users, Is this a bug or a feature?

Also, before all user links in generic_header.tpl, there is a condition:

{if $user or $modvars.Newsletter.allow_anon_registration and !$coredata.logged_in}

May be here a breckets are missed. Also can not see reaosn to exist such a condition here.

It is possible to use template override, but better is to correct in original template.

The link looks like
domain.de/something/&newlang=de

It should be
domain.de/something/#comment1

I think.

port pagemasterplugin to clipplugin

First of all image name is returned in lower case, this leads to broken images if in image name we have capital letters
Output with and without url_check modifier

<img alt="" src="/articles/images/4845_fred_beckey_90_tranquility.jpg"/>
<img alt="" src="/articles/images/4845_Fred_Beckey_90_Tranquility.jpg"/>

Second, I can not see base URL added.
This also leads to see broken images in Email client.
Second issue can be solved anyway, for example adding in html.tpl file in header section:

<base href="http://www.xyz.com/" />

This works with Gmail and MS Outlook, but not checked with other clients.
Adding base URL with url_check modifier will be more reliable.

The frequency of receiving a newsletter can`t be changed anymore.

If title move from template to plugins class method (getTitle?), and order for the plugins move in Newsletter Plugins section (like truncating for example - no need for separate module variable), then templates will simplify, and adding plugins will not require editing templates - just dropping the class in proper folder.

What do you thing? (I'm considering in principal, not at all costs for upcoming version).

index.php?module=Newsletter&type=admin&func=view&ot=user
redirects you to
index.php?module=Newsletter&type=admin&func=edit&ot=user
if you choose a filter.
That's wrong. It should redirect to the same url.

• What should the wiki contain?
• Who wants to write it ;)?