The problem with this code is that it is subverting previous functionality. Before, it used to work in a more open manner, not redirecting to the wizard too much, and allowing for more flexibility with Marketing records (changing templates for different sendings etc). That “secret” edit view is a left-over from those times.
Probably the changes weren’t a good strategic option. They were trying to simplify a complex process, but didn’t do a good job with the new system either; and along the way they reduced functionality. They should have left the old options there, at least for power-users.
I don’t know if the code to duplicate the Marketing record is still there, or if it ever was. modules/Campaigns/WizardMarketingSave.php seems to be doing the save, but it apparently re-uses the previous bean, as you discovered.
One thing you could attempt is to skip the retrieve. This should save the new $marketing bean as a separate record. Hoperfully the rest of the code ties up the knots correctly (copying target lists relationships etc)…
I tested skipping the retrieve and it worked well. I got a new Marketing record, and it seemed to work properly, with target lists etc. But this would need to be more carefully checked.
I noted that with the retrieves commented out, afterwards (not sure when) it duplicated the marketing record once more. I got 3 instead of 2.
Examining the history of the project, I think this might be the moment when it got broken:
Note the title of the commit mentions trying to fix duplicated marketing records. So it seems there were unintentional duplications, and “fixing” that broke the intentional ones…
I also comented out the if/else containing the retrieve, lines 72-78 on 7.11.15, ran campaign the first time, marketing record got created, ran it second time with a different marketing record name, the new record got created as you experienced.
But then, on the email queue, the view has the old (first) market record name and, not surprisingly, the messages are suppressed.
So, the new record is created but the messages inheritate the old marketing record.
I’m afraid this is too demanding, not only for my PHP weak knowledge, but also for the code context. I confess I’m not at par, but i really appreciated all your support and time.
Anyway, I’ll still continue to look into it but I’m afraid I’ll have to live with it (create new campaigns) until someone better skilled fixes it.
That’s one thing I noticed. Before commenting out the retrieve, the dropdown just had the new mktid although the table had 2 more for the same campaign_id.
But after the suppression of the retrieve, the dropdown contained more, can’t remember, I guess all existing.
This is really strange. The concepts of Campaign and Marketing ID are very tangled.
As I said above, I created a Test Campaign and commented out the retrieve if/else, and it worked partially as I said.
Then, after I reverted the situation to the original code, this same Test Campaign remained working partially, correctly creating the new Marketing ID’s. Even the dropdowns show all the existing Marketing ID’s for this Test Campaign but several panels aren’t showing the records they should.
But the old Campaign I had, the one that started this whole thing, still doesn’t create new Marketink Id’s.
Then I created another campaign, the Test Campaign 1. Imagine, it also does not create Marketing ID’s, but Test Campaign does. Very, very odd.
To finalize, I checked the email_marketing and campaign tables, comparing all the above records and I couldn’t find any relevant difference.
EDIT: Just looked at the [fix for unnecessary empty marketing records creation… ] above and compared with my code. Concluded that mine has more code insertion than the fix. I have 7.11.15. Possibly there has been more fixes after that one.
I think we’re not too far from a solution, though I struggle to find time to really dive into this and solve it.
Tweaking that condition gets a new Mk record created, which is what we want. It also copies over relationships to target lists, which gives me confidence that the code was already there to make this happen.
Getting the third, spurious mk records is a bug, we should be able to fix that by watching closely the requests that get generated and having some condition to filter out the spurious ones.
Finally, when creating the new record (the good one, the one we want) we probably need some further adjustment to the POST data that goes over to the next screen, so that the correct new mk record is used, not the new one.
