mumbomedia

Hello @nikelaos

first of all the naming is incorrect.

The files should be named sitemap-de_DE_formal.mo and sitemap-de_DE_formal.po.
Then it will work.

great to hear that.

I assume that it will be announced in your newsletter (which I have of course subscribed to) as before.

I am excited looking forward to the next release so that I can use this as soon as possible.

Have a nice day and stay healthy

Kind regards from Germany

Alexander

It was a tricky one but I managed to get it to work.

Will there be any plans to make it easier to register custom presets, deregister even built-in preset (in case you don’t need them) and modifying existing blocks?

• This reply was modified 4 years, 9 months ago by mumbomedia.

That’s a great idea.
I have installed a svn locally on my computer for another project.
I will make a new repository for this, so I am able to diff you changes in the plugins code.

Because I have subscribe your newsletter I will be informed when a new release is available.

So keep the good work.

Alexander

Hi Stefano,

I understand.
But since I’m also the technical person responsible for the entire WordPress multisite, it doesn’t matter whether I overwrite your plugin code.

From my own experience I know only too well that after the code is in production it revealed to not be a good choice. That’s a problem I’m facing everday and in the most cases it isn’t code that I have written.
Really frustating is it when the code isn’t well documented and / or formated.
I think every developer can sing a song about it.

However actually I’m in a bind.
Personally, I would like to wait for the update.
On the other hand, my boss wants the page to be completely finished as soon as possible so that he can show it to the customer and we can go live (which then means that we can invoice our customer).

When do you think, the plugin update will be available?

• This reply was modified 5 years ago by mumbomedia.

There is a performance improvement opportunity in /newsletter/emails/emails.php:741 – 756
There scan_blocks_dir is unnecessarily called 3 times.
In my opinion, lines 748 – 752 can be omitted.

The directories to search for should instead be set using the existing filter “newsletter_blocks_dir”.
The advantage of this solution would be that you could now remove the standard filter using the “newsletter_init” filter and register your own filter for it, making it possible to overwrite existing blocks.

Hi Stefano,

thanks for the fast reply and your fantastic plugin.
It’s our standard newsletter plugin.
We are using it on each site our customer wants to send newsletter.

Good to hear, that you are working on it.
When do you think, this is possible?

In the meantime I have found a way to archieve this.

I hooked into the newsletter_init hook and then deregister and register and new handler for wp_ajax_tnpc_presets. In this function I got the instance of NewsletterEmails via its static function get_instance.
For testing I reduce the $PRESETS_LIST to array(“blank”) so only the blank preset is shown.

Actually I’m working to make custom blocks for preheader, header, footer and legal notice.

As I have saw in the code I could use the filter “newsletter_blocks_dir” to disable unwanted blocks.

Here’s my actual code:

function mjm_hook_wp_ajax_tnpc_presets(){
	$content = '';
	$newsletter_emails = NewsletterEmails::instance();
	$newsletter_emails::$PRESETS_LIST = array('blank');
	if(!empty($_REQUEST['id'])){
		$preset = $newsletter_emails->get_preset($_REQUEST['id']);
		foreach($preset->blocks as $item){
			$newsletter_emails->render_block($item->block,true,(array) $item->options);
		}
	}
	else{
		$content = "<div class='clear tnpc-presets-title'>" . __('Choose a preset:', 'newsletter') . "</div>";
		foreach ($newsletter_emails::$PRESETS_LIST as $id) {
			
			$preset = $newsletter_emails->get_preset($id);
			
			$content .= "<div class='tnpc-preset' onclick='tnpc_load_preset(\"$id\")'>";
			$content .= "<img src='$preset->icon' title='$preset->name' />";
			$content .= "<span class='tnpc-preset-label'>$preset->name</span>";
			$content .= '</div>';
		}
		
		$content .= '<div class="clear"></div>';
		echo $content;
	}
	wp_die();
}

function mjm_override_newsletter(){
	$newsletter_emails = NewsletterEmails::instance();	remove_action('wp_ajax_tnpc_presets',array($newsletter_emails,'hook_wp_ajax_tnpc_presets'));
	add_action('wp_ajax_tnpc_presets','mjm_hook_wp_ajax_tnpc_presets');
}
add_action('newsletter_init','mjm_override_newsletter');

Because @shabalinse didn’t use the plugin anymore.
Now he is using Yoast Seo as you can see on https://donsport.ru/sitemap_index.xml. Therefore the ticket could be marked as resolved.

Same issue on additional domains.
The strange is that if I access the sitemap from my browser it redirects to the right url and if I check this with the url checker it says that the file couldn’t get indexed because of the X-Robots tag which is correct, because this url should not be indexed but processed.
On another additional domain on the same server it works without any issues.

Couldn’t figure out what’s the matter.

Any help appreticate.

Why do you want it to rename?

If you really need to do it a rewrite via .htaccess could do this.

I could figure out myself how to disable this feature.
I looked into the language file of WP for “technische” and found that this sentence

“The site is experiencing technical difficulties. Please check your site admin email inbox for instructions.”

is on wp-includes/class-wp-fatal-error-handler.php:173.
So I looked into it and found a new define “WP_SANDBOX_SCRAPING”.
As far as I could see from the source code, this should also be a boolean constant.
I have setup these in the wp-config.php and placed a syntax error in my plugin (; instead of,) for testing.
As expected, the result was an empty screen and no longer an e-mail.
So my first question is solved but it would be nice if someone could explain these new constants or include them in the documentation so that other people could benefit from my investigation.

• This reply was modified 5 years, 9 months ago by mumbomedia.

Yes, it’s resolved.

Also I could figure out why WP_DEBUG didn’t work as expected.
The global setting for display_errors was set to true in the php.ini.
By changed it to false, which should be the default on live servers, everything works like expected.

@etiennep

Thanks for pointing this out.
I will change this on our installations.

Strange, in old wp-versions I don’t have to set up these defines:
I believe this correct behaviour has taken place with the opportunity to set WP_DEBUG_LOG to a file path.

As the most installation are live these defines should become standard for wp-config.php. Warnining, notices and errors should only be shown on testing instances.

@etiennep

Glad to hear that.

I’m also curous that this issue was shown althought WP_DEBUG is set to false which should prevent such issues to be shown to the website visitors or potential hackers.
I’ve filed a ticket about this issue also.
I assume that with PHP 7 the messages are thrown as exceptions instead of errors so a exception handler needs to be defined. Maybe this is missing.

@kouteki

By latest version do you mean 1.11.8?
If so I’m sorry to say that the messages @syntax53 posted are still present.

Without the changes @moody1337 posted there is no chance that this messages will not being thrown. Take a look at https://www.php.net/manual/en/function.create-function.php. What could this being misunderstood: “Warning This function has been DEPRECATED as of PHP 7.2.0. Relying on this function is highly discouraged.”?

Also the code @moody1337 is the same as before but now it is using the native anonymous function which is recommended @see https://www.php.net/manual/en/functions.anonymous.php.

So I would recommend to eliminate all create_function calls within your plugin code base and replace them by native anymous function because WordPress will only run without any notices with PHP > 5.5 and not every user of you plugin has the oppprtunity to adjust the php version. In most cases the server works with the latest stable release of php and therefore compatibility with PHP 7 should be mandantory.

• This reply was modified 5 years, 10 months ago by mumbomedia.
• This reply was modified 5 years, 10 months ago by mumbomedia.