Tharkon

Looks like that fixed the issue.

A related issue however to truly be 100% jQuery 3.5 compatible would require fixing a few things in the Slick library since jQuery.type is deprecated as of 3.3 (https://api.jquery.com/jquery.type/). I would still consider this resolved if you choose not to fix that because it looks like that isn’t your code. I have made the following edits myself on my own website that seem to do the trick.

On line 2154:
if( $.type( arguments[0] ) === 'object' ) {
if( typeof arguments[0] === 'object' && arguments[0] !== null ) {
On line 2160:
} else if ( $.type( arguments[0] ) === 'string' ) {
} else if ( typeof arguments[0] === 'string' ) {
On line 2166:
if ( arguments[0] === 'responsive' && $.type( arguments[1] ) === 'array' ) {
if ( arguments[0] === 'responsive' && Array.isArray(arguments[1] ) ) {
On line 2196:
if( $.type( _.options.responsive ) !== 'array' ) {
if( !Array.isArray(_.options.responsive ) ) {

I didn’t mean to share the page as a link, it’s only a relative path within the admin section. I could prepend a domain name, but it wouldn’t work without an admin account on the website.

A little extra detail:
I disabled font awesome on the first tab, Advanced Settings.
I did this to reduce loading times because we make very little use of font awesome and because I expected to be able to manually add a Unicode replacement for the few places I did need special icons.
Then under Custom CSS I added the CSS I posted, because to my understanding, the only place where Font Awesome is used in WP Carousel is for the left and right icons. And this CSS code shows arrows even when Font Awesome is not loaded.

I should also note that I replaced ? with ? because the former would not display properly on Android.

So to summarize, my current code works:

i.fa.fa-angle-left:before {
    content: "?";
    font-style: normal;
}

i.fa.fa-angle-right:before {
    content: "?";
    font-style: normal;
}

But if I were to use Unicode code points instead of the actual characters themselves, as is the normal practice in CSS, I have to escape the slashes, which is in itself not a problem, but I have to re-escape them every time I would visit the page, which is somewhat unexpected behavior.

i.fa.fa-angle-left:before {
    content: "\\276E";
    font-style: normal;
}

i.fa.fa-angle-right:before {
    content: "\\276F";
    font-style: normal;
}

I hope that explains everything. Again, I have already worked around the issue on my website, so feel free to consider this as low priority. Or perhaps all that is needed is a disclaimer on the Custom CSS settings page explaining not to use slashes.

• This reply was modified 4 years, 1 month ago by Tharkon.

We have deleted all instances of shortcoder_data across all our websites to ensure the problem does not reoccur and are currently in the process of copying all entries of the wp_posts table that have post_type=shortcoder from a back-up to our live websites. After that it should be as if the old version never existed.
I had to prioritize restoring our websites over analyzing the bug in this case, so I’m afraid I can’t provide a lot of insight.

Though I guess 3dmakernow’s suggestion of adding a prompt before importing from the shortcoder_data field would make it a little bit more foolproof, and perhaps a button somewhere in the settings to redo this import should it be missed when first upgrading to v5+

Having dug deeper into the function you pointed me to I noticed two things.

First, the functions as represented on
https://developer.www.ads-software.com/reference/functions/wp_targeted_link_rel/
and
https://developer.www.ads-software.com/reference/functions/wp_targeted_link_rel_callback/
are not actually how they are in the current version of WordPress.

Specifically, the current version of wordpress includes a call to wp_kses_hair().
And it this function that causes the problem.
For it seems wp_kses_hair() uses list of allowed protocols, which you can find here:
https://developer.www.ads-software.com/reference/functions/wp_allowed_protocols/

So it is indeed not a bug, but a feature, though not because of it being invalid or because the regex can’t handle it, but because WordPress specifically only allows certain protocols, which are recognized by their colon, so in this case $$custom_field is treated as an unallowed url-protocol.

Therefor the solution in my case was the following code added to functions.php, though I now probably should go and recommend the author of the plugin that makes uses of these custom fields to add it to their plugin’s code.

add_filter( 'kses_allowed_protocols', 'dzb_allow_custom_field_protocol' );
function dzb_allow_custom_field_protocol( $protocols ) {
	$protocols[] = '$$custom_field';
	return $protocols;
}

• This reply was modified 5 years, 2 months ago by Tharkon. Reason: Better name for custom function

I do not think the href attribute has requirements to it’s content to be valid HTML.
Even if it had, the link1$$ it resolves to probably is not valid either.

And either way, WordPress should not try to fix invalid HTML, the img element was not valid, and it left that unaltered.

I’ll dig into that function to see if I can find the cause, but I do still believe that this is a bug because that function should be changing the rel attribute and not the href attribute.

I ran a little test on one of the remaining websites.
Edited one shortcode just prior to updating so I would know what to look out for.
Then ran the update, and while it seems some shortcodes were updated (based on their displayed published date), the shortcode I had edited was not and the edit was not reflected.

I then proceeded to delete all shortcodes in 5.1 (using the built in tools this time, rather than the database editor) and then delete the version option (using the databse editor).
This caused 4 of the shortcodes to reappear with new versions, including the one I used in the test above.

I will just continue using the method as you described above, it’s a few additional steps but so far it seems a certain solution.

Shortcode in version 4.6, as it has been since 9 Jan until just prior to updating today.
https://i.snipboard.io/kiBtNc.jpg

Shortcode in version 5.0 just after updating today, which is identical to how it was on 6 Jan.
https://i.snipboard.io/bSVKs0.jpg

I should add that in order to revert to 4.6, all I did was restore a back-up of the plug-in files.
Either way, your fix works, and that is what matters, just thought I’d show these screenshots since you asked about the content.

I have 37 further websites where the same thing might happen. They all upgraded to 5.0 on 6 Jan after which I reverted to 4.6 using FTP, and have made changes in those shortcodes since. They have not been updated to 5.0 yet. Would you recommend using your fix for those as well, or is there a bette way to prevent it going wrong in the first place?

EDIT: to clarify, for those 37 websites, the outdated shortcoder posts still exist but are not currently in use. The shortcoder_version 5.0.1 option also still exists on those as well as the shortcoder_data option with the correct data.

• This reply was modified 5 years, 2 months ago by Tharkon.

Apologies for the late response, I somehow missed the notification.

I just checked and we already had 1.8.4 installed, the problem remains.
I reverted to version 1.7.29 which I still had lying around in a back-up, the problem remains. I then updated again to 1.8.3, the problem remains.

Some further testing shows that if I include the form on the page as well as the pop-up, then the form on the page will have the “other choice” option appear twice and the one in the pop-up will have it appear three times.

If I don’t include the form on the page but only on the pop-up then the form in the pop-up will have the “other choice” option appear twice.

The fields all have the same id: #input_707_2_other

On one occasion while setting up a copy on https://www.hrdlpn.nl/popupmakertest/ to see if the issue is site-dependant the forum on the page had the “other choice” option appear five times. I was not able to replicate this after that.

Actually I just found a good solution, since this bug appeared in a recent version only. Just install an older version of the plug-in, enter the UA code, then if desired, update to a recent version.

That filter does not actually add the code, it just makes the website act as if it is added, if the code is removed nothing is changed. Surely there must be a way to manually edit it someway, what database entries need to be edited?

I can’t say that it is clean either, it is wasting screen real estate because the editor is a half as wide as the old one, with just empty space in between. Also you’re forced into having two separate scrollbars, one for the editor and one for the sidebar.

I did set the default query matching, but it is only effective for new redirects made after the option is set. Existing redirects keep the Exact match all parameters in any order setting, even when match_data is empty. I tested it with an existing redirect as well and it would not work until I manually changed the individual setting.

Thank you for making the alpha available, it seems to be working for me, but we’ve yet to do some more testing.

In order to have it affect existing redirects, do I change the value of match_data to
{"source":[]} ?

We have thousands of redirects, so manually changing each one is not preferred when a query like this would do the trick:

UPDATE wp_redirection_items SET match_data= ‘{\”source\”:[]}’

• This reply was modified 6 years, 2 months ago by Tharkon.
• This reply was modified 6 years, 2 months ago by Tharkon. Reason: Trying to get ` working within a codeblock

I’ve only noticed it so far in the HTML widgets, which don’t use autosave.
I don’t think the post editor itself uses Codemirror nor any kind of syntax highlighting, so it is not happening there.

The main reason we don’t use the visual editor is because we’ve experienced it breaks things. We also like to be able to actually see the code, making it easier to see if correct styling and attributes are used, for example, the id of a header, the style of an image or the target of an anchor tag. We have some template codes and in the HTML editor we can just copy paste blocks of code from a template to use in a new post or page, while we wouldn’t be able to paste this into the visual editor.

We have updated to WordPress 5.1 and there has been no change in this regard.
I think it might be something that can be worked around though by paying attention. It is just odd and unexpected behaviour, especially when inserting links in existing text.

I have:
Linktext

I type this before it:
<a href="link">

And the result
<a href="link"></a>Linktext

I will just have to adjust and cut and paste the that is autoinserted instead of typing it at the end like normal.