aszele

The issue is primarily with the files in the /wp-content/uploads/mailpoet/cache directories.

They are filled with files that have code similar to below:

wp-content/uploads/mailpoet/cache/6a/6ab4a57b877ff51b76d55696abac4908fc0408ec93ad8c0f8a12b9b9e88341c4.php: return new Source(“”, “newsletter/templates/blocks/social/settings.hbs”, “<OLD HOST PATH>/wp-content/plugins/mailpoet/views/newsletter/templates/blocks/social/settings.hbs”);

While this does not directly cause issues with site display that I have note, it does result in autofs constantly trying to mount the directory structure from the OLD HOST PATH on the new server where that path does not exist. This is filling our syslog with errors and causing issues with the automount service. This is the only reference to that path on the server, so I am trying to remove the paths from the codebase.

Is there any way to purge and regenerate these files (there are hundreds in that cache directory…)?

We’re currently on php 8.1.14. PHP 8.2 is not expected to be released for Red Hat until 2nd quarter this year.

I’ll test with a default theme and report back.

FYI, we migrated to php 8.1 with an existing codebase that used smart-slider-3 version: 3.5.1.19. We didn’t see the memory leak until we upgraded to 3.5.1.21.

We’ve isolated the problem by deactivating slider and noting no memory growth over time, then reactivating it and noting immediate evidence of the leak. It takes about 2 days to consume ~4G of RAM and crash the php-fpm service on the host.

While I appreciate that the issue is likely in the php core itself, it’s being triggered by something in the code updates between the two slider versions listed above. We’re scheduled for os/software patching soon, so hopefully the latest php update will resolve.

Excellent! Thanks again Paul!

Thanks again. Definitely needs testing against other LDAP sources, but might make sense to include it as a checkbox option in the LDAP config page in case it does cause issues outside AD.

• This reply was modified 5 years, 3 months ago by aszele.

That got it! And we’re on fairly similar timelines, because we just worked out yesterday that it was the subtree searches that were failing (if I put in the full OU of the user account, authentication worked).

I was getting confused as our domain functional level is later than 2003. Took me a bit to realize that this option is needed with all newer AD implementations after 2000.

But I threw that line in and confirmed that we’re getting subtree searches now.

Thanks again!

Excellent! Thank you so much for the clarification Paul (and for citing the code snippet – it helped me find the similar process on an old plugin that we’re still temporarily using while migrating to yours!)

Thanks again.