Release 1.0.0 with localization, declare WP 5.7 compatibility

[patrickrobrecht]

• Localize the plugin via Translate WordPress (see support forum)
• Add code style check and make code compatible with WP CS
• Release as 1.0.0 to add a statement on the public API (as done for (SPCL](Release 1.0.0 with localization, declare WP 5.7 compatibility #20 (comment)) as well)
• Declare compatibility with WordPress 5.7

[Zodiac1978]

I am not able to give feedback to all of the changes (no knowledge about composer), the rest looks good to me!

Just a question (although the problem is not in the PR, it exists before, just saw it now):
If we add the sentence: "Next check for a new block list in" but the event is not scheduled and returns false it ends up with the sentence: "Next check for a new block list in never". Better than "Never" (capitalized), but still no real sentence, or not?

[stklcode]

Technically LGTM.

However, we do jump from 0.0.6 to 1.0.0 and already adjusted wording from black- to blocklist in various places. Isn't this the point in time where we might consider renaming the plugin itself to, let's say Blocklist Updater ?

I've recently done the same for Statify Blacklist (now Statify Filter) preserving the old slug, which didn't cause any trouble.

[patrickrobrecht]

However, we do jump from 0.0.6 to 1.0.0 and already adjusted wording from black- to blocklist in various places. Isn't this the point in time where we might consider renaming the plugin itself to, let's say Blocklist Updater ?

I totally agree here. As we use "block list" in the frontend already, I've updated the plugin name to Block List Updater as rephrased all descriptions from blacklist to "block list" (2 words). Just the slug and class/method prefix stays "blacklist".

[splorp]

Will it cause any problems for this plugin once I finally get around to renaming my Comment Blacklist for WordPress?

I’d like to take the direction you have and rename the project to “Comment Block List for WordPress” … also changing the repo name from wordpress-comment-blacklist to wordpress-comment-block-list. It appears that GitHub will automatically handle redirection of the legacy slug to the new repo path, so that shouldn’t be an issue.

[patrickrobrecht]

@splorp Thanks for asking. The redirection should handle everything, otherwise we'll publish a bugfix release immediately. I've subscribed to splorp/wordpress-comment-blacklist#27, so I'll get notified if you close the issue.

We'll keep the slug as WordPress.org does not allow to change plugin slugs.

[splorp]

Cool. Sounds good.

[stklcode]

LGTM.

We should though Update the GH action versions to keep it consistent across our plugins, i.e. actions/checkout@v2 and 10up/action-wordpress-*@stable

blacklist-updater/.github/workflows/wordpress-plugin-asset-update.yml

Lines 11 to 13 in 26f78e5

	- uses: actions/checkout@master
	- name: WordPress.org plugin asset/readme update
	uses: 10up/action-wordpress-plugin-asset-update@master

blacklist-updater/.github/workflows/wordpress-plugin-deploy.yml

Lines 12 to 14 in 26f78e5

	- uses: actions/checkout@master
	- name: WordPress Plugin Deploy
	uses: 10up/action-wordpress-plugin-deploy@master