squarecandy

Fantastic, thanks. We will take a look and test it later this week.

Sounds great, thanks for looking into it!

Here’s some info about using aria-expanded if you wanted to implement that at the same time to help out screen reader users:

https://www.accessibility-developer-guide.com/examples/sensible-aria-usage/expanded/

Whoops, looks like your email is not working currently.

554 5.1.1 <[email protected]>: Recipient address rejected: undeliverable address: host mail-outgoing.**************.local

550 5.7.1 <[email protected]>: Recipient address rejected: Mailbox is out of service (in reply to RCPT TO command)

Awesome, thanks for the info! Really looking forward to seeing 4.0 and how things progress. Sending you an email about a few other things separately.

Thanks @gmorrison for posting here.

I just wanted to clarify some of the research we have already done and what we are asking for from the WC dev team.

The existing situation:

• The existing setup to connect to stripe definitely encourages a default to using Standard Keys. There have been some claims that Restricted Keys work, but they appear to trigger errors in the dashboard when implemented, even if they technically work. See https://github.com/woocommerce/woocommerce-gateway-stripe/issues/634
• The standard setup also stores the keys in plaintext in the database. This is a highly insecure setup. Especially when paired with an unrestricted key, but both should be resolved.

What are we asking for?

• Full support for Restricted Stripe API Keys
• Full documentation for how to use/setup Restricted Keys and what the minimum required permissions are
• Ability to add all sensitive settings (Test and Live Secret and Publishable keys + test and live webhook secrets) via constant in wp-config.php

But I think more importantly – after those things are accomplished we want to see the documentation for setup change so that it encourages the most secure secure setup from the start, instead of the easiest to implement.

You can see our proposed shim solution here, but we would much rather see these features actually integrated into the plugin code. https://github.com/squarecandy/woocommerce-stripe-securit

+1 – yes please.

It’s also I think fine to keep it as a plugin that is supported by the @wordpressdotorg team and Automattic indefinitely.

Has anyone here heard any updates on an official EOL for this plugin?
This post from November 2018 has some old and somewhat contradictory info in it:

Classic Editor Plugin Support Window

First it says…

The Classic Editor plugin will be officially supported until December 31, 2021.

… indicating that it will hit EOL Jan 1 2022. But then it also says…

In 2021 we will evaluate continuing maintenance of the plugin, based on usage. We expect continued maintenance to be fairly trivial.

Anyone heard anything official on the matter? Huge decisions about our entire fleet of custom websites is on the line, and I’m sure many of you are in the same boat. All of the options if official Classic Editor support gets dropped seem equally bad: Convert Everything to Gutenberg; Be responsible for maintaining Classic Editor by ourselves; Move to something like ClassicPress; Have outdated insecure plugins. #4 breaks our contract with our clients and 1-3 all involve massive amounts of time/labor.

I’m getting this too – but not related to Advanced Editor Tools plugin. Did you find a fix? Just on any site with Classic Editor in FireFox

Yes – it’s weird – I’m also seeing it working on my staging server right now with the same PHP version, but not on my local machine…

Hi – I am also experiencing this issue and I dove a little deeper into the root cause. It looks like it is only a problem for the 4.x version. 5.x version populates fine.

Short term solution – for other users who find this before it is solved:
Copy and paste the value of ACFFA_icon_data in the wp_options table from a backup or other site that has valid data for 4.x – here is mine in case it is useful:
https://gist.github.com/petertwise/e2ef15bea3bfa044e8b8ae528a3b31bf

Long term – for the developer:
/assets/inc/class-ACFFA-Loader-4.php – the regex on line 206 does not seem to work with PHP 7.4. I took a bit of time to try and fix it but I could not come up with a solution. Anyways – this is definitely where the problem is coming from – that regex just returns empty arrays instead of parsing out the slugs from the css file.

Suggested easy fix:
since the 4.x branch of fontawesome is EOL maybe the find_icons function could just return a hard coded list of the 4.7.0 icons?

• This reply was modified 3 years, 11 months ago by squarecandy.

It may not result in negative consequences for “discoverability” but it could have negative consequences for people who have spent time crafting how the output of their sitemap works. Examples:

• You have hidden specific pages like form thank you pages or a page with a survey intended to only be accessed via a direct link. The default wp-sitemap.xml could cause these pages to become indexed.
• You want an entire custom post type not to be indexed.
• You have carefully set the priority levels of different posts and post types according to your needs

I would advocate for adding add_filter( 'wp_sitemaps_enabled', '__return_false' ); to this plugin so we can be sure if we turn on Google XML Sitemaps that there’s no conflict with the core feature.

+1 for this

Yes, thanks @ande1352 !!!

Awesome – thank you. Happy to help test it before you push the new version if you would like… My contact info is at https://squarecandy.net

Or if you want to disable the ACF javascript on ALL taxonomy pages:

function squarecandy_yikes_acf_taxonomy_sort_hotfix($post_id) {
	$screen = get_current_screen();
	if ( 'edit-tags' == $screen->base ) {
		wp_deregister_script('acf-input');
	}
}
add_action('current_screen', 'squarecandy_yikes_acf_taxonomy_sort_hotfix', 99);