annaam

Well I spoke a bit too soon, one warning appeared with this new update in our debug log:

[03-Mar-2026 19:30:18 UTC] PHP Warning: Undefined property: stdClass::$send_on in /sites/website/files/wp-content/plugins/newsletter-archive/plugin.php on line 180

ip address – standard [03/Mar/2026:13:30:18 -0600] “GET /?na=archive&email_id=47 HTTP/2.0” 200 14865 “-” “Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/145.0.0.0 Safari/537.36”

It is consistently reproducible.

Thank you for your fast response.

Confirmed, the issue is resolved with 3.8.14.

Best,

Response from Ultimate Dashboard:

We looked into this and concluded that this is an issue with the Posts 2 Posts plugin.

The culprit is init_args() in posts-to-posts/admin/tools-page.php#L17
It uses a raw array assignment instead of merging, so it wipes out all the defaults that check_args() had populated in posts-to-posts/vendor/scribu/scb-framework/AdminPage.php#L508

Fix suggested for “Posts 2 Posts” plugin:

The fix belongs in P2P_Tools_Page::init_args() – it should use wp_parse_args() to merge onto existing args instead of replacing them.

This:

function init_args() {	$this->args = array(		'page_title' => __( 'Connection Types', P2P_TEXTDOMAIN ),		'page_slug' => 'connection-types',		'parent' => 'tools.php'	);}

Should become this:

function init_args() {	$this->args = wp_parse_args( array(		'page_title' => __( 'Connection Types', P2P_TEXTDOMAIN ),		'page_slug'  => 'connection-types',		'parent'     => 'tools.php',	), $this->args );}

This preserves all the defaults from check_args() while still allowing init_args() to update the translated page_title.

Continuing the conversation here so others with the same issue have all the information.

You emailed back: “I took a look at your website and it looks like you put the archive shortcode in the same page as the main Newsletter shortcode. This can cause the page title error you’re getting. Please, try to create a dedicated newsletter archive page with the shortcode, and check if the error persists.”

My director does not want me to split up the newsletter and subscription; they much prefer the look of them both on the same page. So, not trying to go against your continued recommendation, I just need to adhere to what is asked of me and cannot change it unless actually functionally necessary.

I split them up on a testing website, and the issue persisted. Through my own testing, it appears that when we have the archive setting “Showing the newsletter” set to “Embedded on the same page”, the issue occurs, regardless of whether we split it up. When we set it to either of the other 2 options, the issue is immediately resolved, as it uses the na=view, not na=archive. This seems like a bug in the newsletter plugin on the na=archive page, not an issue due to us using it on the same page.

The reason I even noticed this issue in the first place is because we are doing testing to maybe swap our search engine from relevanssi to google search. In google search, results with newsletters were showing the {email_subject} as the title of the newsletter. This is still happening, even after changing the archive settings, as it still is using the na=archive…

So the “View online” issue was resolved by changing the archive setting “Showing the newsletter” to “open in a new tab”. But, the search engine issue remains. It seems our site just isn’t working well with na=archive. I can’t understand how splitting would potentially fix that, and it didn’t on our testing website. We aren’t doing anything crazy with newsletter, just sending one out every other month… sigh. Not sure what is happening.

• This reply was modified 3 months, 2 weeks ago by annaam. Reason: clarity

Do you have an email I can send the link to? I cannot share the site url publicly.

Revealing all of our system info is a security hazard and I’d rather not share again (I’ve shared with you in another thread previously), unless actually necessary. This appears to be warnings that would occur on any site, regardless of other plugins, as I can’t imagine a way another plugin could be interacting with wpdatatables to cause this issue…

If this is not something that is reproducible, aka it is only happening on our site, then I would be open to sharing our system info again.

Environment: php 8.3, wordpress 6.9.1, wpdatatables 7.3.3.

WP_DEBUG is not enabled. I can see these errors through the debug.log.

We stopped receiving the error (without needing to split) after the code on line 42 was fixed to properly die when email_id is empty.

We no longer receive the error in our log.

Thanks.

Can confirm in version 7.2.3, this has been patched.

Thank you.