ellmann creative

Just ran into the same issue.

Having a “missing WP function” issue usually indicates that you’re doing things out of order – you’re trying to execute code that relies on WordPress code before WordPress has had the chance to load it.

I just looked into the old version of the file, and I’m right: you’re executing code outside of any WP hooks or filters! Of course is_plugin_active isn’t going to be defined yet! WordPress can’t guarantee execution order if you’re not willing to use the mechanics it exposes to ensure it.

I once again remind you: loading WP code out of order (like you’re doing here, including plugin.php directly) may cause errors if something else (like… WordPress!) tries to load it at the correct time.

The correct way to do this is by hooking into an init hook (like init). This ensures that your code is called after WordPress has finished setting things up for you. All code that relies on WordPress API should be executed with hooks and filters.

So, it seems tar/tgz behaves better – I suppose it has to do with how the archive creation is handled (direct OS command vs constructing via ZipArchive, I assume?).

However, there’s a separate issue with the tar/tgz format:

WARNING: File name "wp-content/plugins/woocommerce/packages/woocommerce-blocks/build/product-add-to-cart--product-button--product-image--product-price--product-rating--product-sale-bad--49d3ecb2.js" is too long to be saved correctly in TarGz archive!

(same is true for ‘Tar’)

I’ve actually had issues unpacking tar/tgz archives created by BackWPUp in the past, which is why I generally avoid using it if I can help it. I believe it was a general problem with disk space – there wasn’t enough space to create the archive, but the plugin was never notified; on top of that, I found out “the hard way” when a plugin failed to update (ran into 0 bytes free and never completed) and broke the site, and it turned out that recent backups were broken.

(no – we left enough space on the disk for backups and adjusted the number of files kept accordingly; the client started uploading images in .tiff format at like 50-70 MB/image though, and we found out when they came back with “boo hoo our site is broken fix plz” a year later)

Ideas?

• This reply was modified 1 year, 3 months ago by ellmann creative. Reason: Added info on why I stay way from tar/tgz

I’ll give it a shot sometime this week and report back. I hope that’s OK.

Okay. I suppose I’ll mark this as “resolved”, since there’s nothing more that needs to be (or indeed can) be done here.

Thanks.

Thank you for the reply. Our use-cases are, in the overwhelming majority, company sites with little to no logins and (usually) no user registration, so we’re OK with locking IPs out on even a single mistake.

Still, it would be good to be able to separate “NX account” from other lockout reasons, so that I could focus on issues that I actually need to take action for. ??

Thanks.

Did Malware Expert create an exception? Or did you guys change things?

Because it seems to be uploading fine right now, and I’m looking at WF version 7.9.2 still.

Unfortunately, I don’t have that info – the site in question is being hosted by a service provider (I would name-drop, since it’s not a secret – but if we work out bypasses, I’d rather not paint a target at their back).

I can’t get you anything beyond basic info – and the interesting details are obscured. I know they use ProFTPd for the FTP server, but considering that package, it probably won’t tell you much. I have SSH access, but it’s very clearly jailed, so I can’t tell you much about it either.

I tried looking up the kernel version it’s running, but – no luck on that end; best I could get was that it’s probably associated with some sort of cloud-oriented distribution, which again tells us little.

Also, I have used WordFence with this server before (on multiple deployments; it’s our initial staging location). Haven’t had issues uploading WordFence there before, so it’s either a recent change or I haven’t uploaded a new site wholesale in a while. ??

I could try uploading it zipped, see if that triggers or not… I could also try pulling the file via server-local means (instead of pushing it via FTP). But it doesn’t change the fact that the best solution would be one that fixes the issue on WF’s end (so that this doesn’t trigger). I would rather not have to take special measures like this every time I upload a site, after all.

If I may suggest something?

Maybe it would make sense to:

• separate the libs from the signatures (whatever they are),
• make the inclusion of the signature file conditional on it existing, and
• download it should it not be present?

Otherwise – would it make sense to encrypt these signatures (using something weak, why not) to obscure them from A/V software?

To clarify: the plugin works fine with the current version of WordPress (as far as I’m aware).

Wordfence (and other similar solutions) simply take the last-updated time and judge “activity” based on that. A plugin that hasn’t been updated will likely have security and compatibility issues, but “likely” does not mean “for certain”. A plugin that is simple enough has low chances of breaking in subtle ways (the less of the API it uses, the less chances of it breaking when things change), so the rule of thumb is: if it looks OK, it probably is OK.

All the plugin probably needs is a bump in the “tested for” field, which may (or may not) also count as “activity” to satisfy security/maintenance plugins.

The latest available at the time of the submission of the ticket (it was a fresh install, I was testing the functionality). I have since uninstalled it, because it seemingly didn’t work.

Yeah, okay… but I just wanted to know if there’s a reference I could look up to trigger email resending (since the functionality clearly exists). I thought I’d ask before digging into your code myself.

Can you tell me if there’s an API I could use within WordPress (in a plugin, for example) to query your plugin on this? Though I suppose, since your plugin does not do retries, I could safely list the attempts identified as “failed”, or just talk to the DB directly… though, if possible, I’d rather do it through your API (so as to not step on anyone’s “toes” between plugins).

Is there a way I could ask Postman to retry sending a failed e-mail? There’s a “retry” link; I assume I could do something similar?

That way I could write a simple CRON plugin that would a) list failed, and b) try to send them one by one, until there’re none left.

Yeah, I do have that… but I don’t have a fallback SMTP service.

I’m more interested in retrying down the line, instead of a failover.

I checked – it’s set to “English (United States)”.

It’s weird though… I can see it split between EN and PL, even in the menu:

"Dashboard" (EN), followed by
"Dziennik wysy?ki e-mail" (PL), then
"Ustawienia" (PL),
"Contact Us" (EN),
"Support Forum",
"Add-Ons" and
"Upgrade"

Any known conflicts with plugins like Polylang?

Diagnostic test report, as requested. NOTE, I have made edits and they are clearly marked using ##.

Mailer: postsmtp
HostName: ## DOMAIN ##
cURL Version: 7.75.0
OpenSSL Version: OpenSSL/1.0.2k-fips
OS: Linux v5388 4.19.0-21-amd64 #1 SMP Debian 4.19.249-2 (2022-06-30) x86_64
PHP: Linux 7.4.33 C
PHP Dependencies: iconv=Yes, spl_autoload=Yes, openssl=Yes, sockets=Yes, allow_url_fopen=Yes, mcrypt=Yes, zlib_encode=Yes
WordPress: 6.1.1 de_DE UTF-8
WordPress Theme: Wilmer Child
WordPress Plugins: Polylang, WP Activity Log for Yoast SEO, BackWPup, CF7 Smart Grid Design Extension, Contact Form 7 Polylang extension, Contact Form 7, CookieYes | GDPR Cookie Consent, Disable XML-RPC, Nested Pages: Subcategories, Enable Media Replace, Envato Market, Flamingo, Force Reinstall, Health Check & Troubleshooting, Hummingbird, WPBakery Page Builder, Polylang/WPBakery image filter fix, Popup Builder, Post SMTP, Really Simple SSL, Regenerate Thumbnails, Sucuri Security - Auditing, Malware Scanner and Hardening, Wilmer Core, Wordfence Security, WordPress Exporter v2, Yoast SEO, Nested Pages, WP Activity Log, Smush, WP-Sweep
WordPress wp_mail Owner: /## DOMAIN PATH ON DISK ##/public/wp-content/plugins/post-smtp/Postman/PostmanWpMailBinder.php
WordPress wp_mail Filter(s): wp_staticize_emoji_for_email, PostsmtpMailer->get_mail_args
WordPress wp_mail_from Filter(s): wordfence::fixWPMailFromAddress
WordPress phpmailer_init Action(s): wpcf7_phpmailer_init, PostsmtpMailer->phpmailer_smtp_init
Postman: 2.3.1
Postman Sender Domain (Envelope|Message): ## DOMAIN ## | ## DOMAIN ##
Postman Prevent Message Sender Override (Email|Name): No | No
Postman Active Transport: SMTP (smtps:login://## SMTP SENDER HOST ##:465)
Postman Active Transport Status (Ready|Connected): Yes | No
Postman Deliveries (Success|Fail): 1211 | 13

Notably, I’m not sure where it gets that WP is 6.1.1 de_DE – when I originally installed PL, it handles three languages (PL, EN, DE), my admin area is set to EN, and the plugin is partially displaying in PL… ??

Yup, if you have debugging enabled, this will pop up. “Notices are errors” and all that jazz, guys.