videomike

There seems to be an issue indeed, it was already described over there:
https://www.ads-software.com/support/topic/incorrect-replacement-of-fonts-embedded-via-server-link/
I seem to run into the same problem with the brooklyn theme by united themes.
@asadkn – could you have a look at that?
Thanks in advance

Mike

Sigh – now exactly what I wanted to avoid happened again.
Today the latest Update of the plugin was released and … my site was broken again.

Please change the lines 54 and following of /erp/vendor/symfony/polyfill-mbstring/bootstrap.php to

if (!function_exists(‘mb_ord’)) {
function mb_ord($s, $enc = null) { return p\Mbstring::mb_ord($s, $enc); }
}
if (!function_exists(‘mb_chr’)) {
function mb_chr($code, $enc = null) { return p\Mbstring::mb_chr($code, $enc);}
}
if (!function_exists(‘mb_scrub’)) {
function mb_scrub($s, $enc = null) { $enc = null === $enc ? mb_internal_encoding() : $enc; return mb_convert_encoding($s, $enc, $enc); }
}

Then WP ERP will not break sites after every update.

Hi @thebengalboy

No worries, the solution works fine for me now.
I would just ask you to remember this when the next update of the plugin is planned. I had this solution in place about a month ago and when the last update for WPERP came 3 weeks ago, it killed my website. I just want to make sure this does not happen again…

Thanks in advance

Mike

Hello @thebengalboy

Thanks for your quick response. I know the pain of trying to make plugins compatible. And I am fully aware that it is simple not possible to test you plugin with every combination of other plugins.
Nevertheless in this case it is very easy to make your plugin compatible (maybe also with a lot of other plugins that I don’t even know of if you change a few lines of code:
If you have a look at line 55 of /wp-content/plugins/erp/vendor/symfony/polyfill-mbstring/bootstrap.php , and change it to the following:

if (!function_exists(‘mb_ord’)) {
function mb_ord($s, $enc = null) { return p\Mbstring::mb_ord($s, $enc); }
}
if (!function_exists(‘mb_chr’)) {
function mb_chr($code, $enc = null) { return p\Mbstring::mb_chr($code, $enc); }
}
if (!function_exists(‘mb_scrub’)) {
function mb_scrub($s, $enc = null) { $enc = null === $enc ? mb_internal_encoding() : $enc; return mb_convert_encoding($s, $enc, $enc); }
}

This will make it compatible (and by the way is what I did to solve the problem for now.)

Cheers

Mike

P.S:I also checked the code in the email encoder plugin:
if ( ! function_exists( ‘mb_ord’ ) ) :

function mb_ord( $string ) {
if ( extension_loaded( ‘mbstring’ ) === true ) {
mb_language( ‘Neutral’ );
mb_internal_encoding( ‘UTF-8’ );
mb_detect_order( [ ‘UTF-8’, ‘ISO-8859-15’, ‘ISO-8859-1’, ‘ASCII’ ] );

$result = unpack( ‘N’, mb_convert_encoding( $string, ‘UCS-4BE’, ‘UTF-8’ ) );

if ( is_array( $result ) === true ) {
return $result[ 1 ];
}
}

return ord( $string );
}

They do check for the existence of mb_ord before introducing the function, so they do it absolutely correctly – there is no way for them to make it compatible, the needed changes are in /wp-content/plugins/erp/vendor/symfony/polyfill-mbstring/bootstrap.php …

• This reply was modified 5 years ago by videomike.

Thanks! For now I went back to version 1.53 . That works well…

Hi Sergey

Thanks for your hint. I changed all occurrences in the plugin to the renamed and now it works ??

Thanks for your super quick reaction!

Mike

It seems the post id is posted as a hidden variable and probably this was where the global $Ajaxpid was formerly filled from…
I could use the {PostID} Variable and extract it from the mail body… although that is not very elegant and might confuse the people getting the user message in the mail…

I have AJAX activated, so the form posts to the Ajax handler and thus get_the_ID() does not return the post ID of the sending page but is empty…

Thank you Bastian!
Now I can access the email admin again – unfortunately what I did before is not working nevertheless.
I have a forms contact form that is embedded on quite a few pages. there is a custom meta value on each of these pages where the admin address is stored.
I used to read that value and if it was set replace the email address like so:

function my_cforms_logic($cformsdata,$oldvalue,$setting) {
if ( $setting == “adminTO” ){
if ( $oldvalue==’generalcontact@somedomain’ ) {
global $Ajaxpid;
$contact = get_post_meta($Ajaxpid, ‘contactaddress’, true);
if (isset($contact)) { return $contact;}
}
}
return $oldvalue;
}

Now it seems $Ajaxpid is not populated – how can I access my post_meta from within the filter?

Michael

Same problem here. What seems to happen is that the picture URL gets truncated to only one letter after the domain, thus no pic can be displayed… ??

Hi I have seen the same behavior on clients sites, I am also looking for the root cause.
I have checked the creation date of those files and compared that with the access log of the server, but could not see any suspicious access. How is the creation of these files triggered in the first place? What can be done to prevent it?

That is also exactly what I need – is it possible with wp-pro-quiz or do I need another plugin for that?

Hi WP-Lefty

Wow that was a quick answer.
While it might be a solution for people creating their own themes or coding their own widgets, it does not really help the “widgets only” users. Why not implement a checkbox and only add an extra class when the checkbox is checked. This would not interfere with existing setups at all as the output would stay the same when the checkbox is not ticked.

Mike

It doesn’t seem to save the widget id in the options
I added the following code in line 263 of widget_logic.php

$id_disp=$id;

(that is in function widget_logic_extra_control_new, just before the echo line that does the output)
Seems to do the trick on my wordpress multisite install.

What exactly does line 1 look like in widget_logic.php? There should be no eval command there, so this could be a sign that your wordpress install has been hacked and some files (probably not only in the widget_logic plugin) have been altered to contain a eval(somecode) line which executes malicious code…