Migration to new website: not send mails

Hello,

Could you make sure that this tool migrates the database correctly (preserving the InnoDB engine and the constraints/foreign keys)?

You can click the “Check database integrity” button in the AcyMailing configuration page, advanced part of the “Security” tab and check if there are some issues found.

Hello,
I created 2 new WordPress installations (A and B) for testing.
Plugins: WPvivid, AcyMailing
Then automatic migration from A to B.
DB type is InnoDB.
Check database integrity: issues found and fixed.
New test for sending a newsletter: error still exists.
The same result with Plugin Backup Migration.
What else can I do? Otherwise the plugin is very good.
If it helps I can set up an admin for you.

@m266 This is bad and can get @acyba banned from this site and their plugin removed from this site

If it helps I can set up an admin for you.

If they even temporarily accept that access then they will be banned from this site. Also they accepted that and that was bad. I archived that reply.

@acyba

While I know you have the best of intentions, it’s forum policy that you not ask users for admin or server access. Users on the forums aren’t your customers, they’re your open source collaborators, and requesting that kind of access can put you and them at high risk.

If they are paying customers (such as people who bought a premium service/product from you) then by all means, direct them to your official customer support system. But in all other cases, you need to help them here on the forums.

Thankfully are other ways to get information you need:

• Ask the user to install the Health Check plugin and get the data that way.
• Ask for a link to the https://pastebin.com/ or https://gist.github.com log of the user’s web server error log.
• Ask the user to create and post a link to their phpinfo(); output.
• Walk the user through enabling WP_DEBUG and how to log that output to a file and how to share that file.
• Walk the user through basic troubleshooting steps such and disabling all other plugins, clear their cache and cookies and try again (the Health Check plugin can do this without impacting any site vistors).
• Ask the user for the step-by-step directions on how they can reproduce the problem.

You get the idea.

We know volunteer support is not easy, and this guideline can feel needlessly restrictive. It’s actually there to protect you as much as end users. Should their site be hacked or have any issues after you accessed it, you could be held legally liable for damages. In addition, it’s difficult for end users to know the difference between helpful developers and people with malicious intentions. Because of that, we rely on plugin developers and long-standing volunteers (like you) to help us and uphold this particular guideline.

When you help users here and in public, you also help the next person with the same problem. They’ll be able to read the debugging and solution and educate themselves. That’s how we get the next generation of developers.

Hi Jan,
these are harsh words for a dedicated user, translator of WordPress plugins and author of tutorials. Member Since: May 30th, 2010. The admin access was only planned for a test website, so no danger. I will try the other options.
@acyba: I’ll test and report later.

Greetings

these are harsh words for a dedicated user, translator of WordPress plugins and author of tutorials.

No, it is not. Please actually read what I wrote as opposed to what you think I wrote.

That verbiage was produced by several moderators and I use it for a reason. You can make me a “bad guy” if that somehow appeals to you but try not to read into the written word what isn’t there.

The admin access was only planned for a test website, so no danger.

The restriction still exists and it being a temporary, a staging site or some test site does not change that.