Categories are not saved about direct_mail_subscription

[nitsan-technologies]

@ Cedricziel: Here is the solution as below:

# Ext: direct_mail_subscription

# System Environment:
TYPO3: 7.6
Extension: 2.0.3

# Problem:
Category not listing using cObject CATLIST (setup.txt)

# Solution:
In latest version of direct_mail_subscription, Category listing in displayed in FE which is render through plugin.feadmin.dmailsubscription.cObject. To display category in Frontend one need to change as following

cObjects {
CATLIST = USER
CATLIST.userFunc = user_dmailsubscribe->makeCheckboxes
CATLIST {
templateFile = {$plugin.feadmin.dmailsubscription.file.templateFile}
pid = {$plugin.feadmin.dmailsubscription.pid}
hideNonTranslatedCategories = 0
}
}

Replace with

cObjects {
CATLIST = USER_INT
CATLIST.includeLibs = EXT:direct_mail_subscription/pi/class.dmailsubscribe.php
CATLIST.userFunc = user_dmailsubscribe->makeCheckboxes
CATLIST {
templateFile = {$plugin.feadmin.dmailsubscription.file.templateFile}
pid = {$plugin.feadmin.dmailsubscription.pid}
hideNonTranslatedCategories = 0
}
}

[kartolo]

the static TS is corrected. Is the saving problem still exist? on my dev server the chosen categories are saved without problem. It's a plain 7.6 installation

[magesticmojo]

I still have the saving problem: TYPO3 7.6 and the latest extension-code from master:
The checkboxes are now rendered (thanks for the fix) but the selected categories are not saved in the tt_address-table. Any advice?

[kartolo]

@mojobsb: the categories are saved in a MM table "sys_dmail_ttaddress_category_mm"

[magesticmojo]

@kartolo: Sorry, I was unclear: A value (count?) gets saved in tt_address.module_sys_dmail_category but no entries in sys_dmail_ttaddress_category_mm. The BE shows the categories but they are never selected. Any idea how to fix this?
Thanks a lot!

TYPO3: 7.6
tt_address: 3.0.3
direct_mail: 5.1.0
direct_mail_subscription: 2.0.3

[magesticmojo]

It seems user_dmailsubscribe->saveRecord() never gets called after saving a new subscriber.
An ugly workaround is to change user_feAdmin->userProcess_alt() to:

    public function userProcess_alt($confVal, $confArr, $passVar)
    {
        if ($confVal) {
            $funcConf = $confArr;
            $funcConf['parentObj'] = $this;
            // $passVar = $GLOBALS['TSFE']->cObj->callUserFunction($confVal, $funcConf, $passVar);
            require_once('pi/class.dmailsubscribe.php');
            $user_dmailsubscribe = new user_dmailsubscribe();
            $passVar = $user_dmailsubscribe->saveRecord($passVar);
        }
        return $passVar;
    }

@kartolo: Could you please investigate this and fix this in the next version? Thanks!

[kartolo]

please check my commit (develop branch). I just found out, that there's difference between callUserFunction in ContentObjectRenderer and GeneralUtility.

[RonnyGitHub]

We had the same problem, and checked the commit. The develop-code worked for us! Thanks a lot.

+1

[magesticmojo]

Works fine for me, thank you!

[ikkez]

why is this fix not closed and not included in the TER version? Please add it to 2.0.4, otherwise it drives people crazy. thanks.