kiwi3685

Same problem here. I upgraded WP yesterday and had to disable this plugin to use the site. I have been monitoring this topic for the fix.

Just installed v.10, and re-activated. Everything works works as normal again.

I very much appreciate this plugin, and am grateful for your fast fix. Much appreciated.

Thanks for the link. I’ve never used WP-CLI, and not sure I can anyway. But that code looks ok. I’m sure I can run it some other way.

I think I have a better solution, which avoids over-writing the code change on update.

Got to “customise > add custom css” and add this:

.main-slider .main-content a.btn i.fa-shopping-cart {
	display: none;
}

Thanks for the reply. I don’t understand your comment about the stack trace, and ” (that’s the issue with the error message sent by email)“. What I included here is all that exists in my error log file on the server, and I haven’t sent it anywhere by email.

Regardless, I did approach the developer of GD Topic Prefixes before I came here. His comment was:

I never used that plugin, and I have no idea what it attempts to do here. My plugin uses the same method to deal with the prefixes as bbPress does with the topic tag, and it uses the bbPress approach to dealing with the prefixes, to avoid conflicts.

This error shows that Polylang can’t deal with the term in the query, if the term is defined as a WP_Term object, so I would expect that Polylang should be fixed and check if the term is defined as an object or array (both are valid in WordPress, and often are interchangeable).

I will pass your comment on to him, but then I would prefer that you two discuss this together, No point me getting involved in a dispute between developers. The support request there is https://support.dev4press.com/forums/topic/error-when-selecting-prefix-link/

In the short term I can “fix” the issue by commenting out lines 44-46 in function have_translated_taxonomy() in plugins/polylang/include/query.php as mentioned above.

For further information…

Updated to ver. 2.8.3. No change to this issue.

Thats great. But it would be a LOT easier if we were told what had changed to cause the error to only happen after the update. Then we would need to spend hours guessing.

Yes I do need help.

I have created NO new redurects. All I have done is upgrade the plugin.

So the upgrade must include s change which is causing an existing redirect to fail, which did not fail before.

What might that change be?

Sounds identical to the one I reported a week or so ago. Sadly no answer to mine yet. Im looking for another plugin.

Thanks, but updating to 4.16 makes no difference to this problem.

So the question begs: do you really value MailPoet at just $50?

I wish I could say no – but given that it runs on a free software platform (WordPress) then I’m afraid I must, especially when my own product is, like WordPress, provided for free.

But as I’ve said elsewhere, I have no issue with you making money. I just disagree a little with your determination of where the free vs pro/paid versions differ. I’d like to see the same basic stats in MP3 as you gave for free in MP2.

What would it take for you to spend on a plugin like ours?

For me, as a developer of an open-source free product with a very small user base, it would take a mid-range product (Mailpoet 2.5?), with basic user-level statistics and a price point of (say) $50 – ideally a one-off payment, not annual.

Question not directed at me, but 100% definitely getting the basic stats.

This is very disappointing. Switching back to MP2 is the only obvious solution (other than switching to alternative solutions, but I am sure that soon MP2 will be discontinued.

Premium is far too expensive for small mailing lists (I have less than 200 users and only send 3 or 4 emails each year for an open source / free software project). The cost is far too high.

MP2 provided only basic statistics at the user level. Surely you can reinstate that and retain more detailed statistics for premium – pleeeese?

Thanks for the reply, though it is disappointing.

I prefer to keep the MP2 newsletter archive permanently available, so keeping the old plugin active is not really a practical solution. But (I hope) the old newsletters are in the database and should remain there permanently even if I remove the plugin. Can you confirm that?

Providing that is the case I shall write my own short-code based on the one in MP2, to allow continued access combined with the newsletters generated from MP3.

Failing that I shall have to convert them to PDF’s as per my second option above and add the links to the MP3 archives page.

10 months later and still no response??

I agree this would be a helpful improvement. Can anyone from Twitter comment please?