1.3.4 Compatibility Release for WordPress 6.7

1.3.4 Compatibility Release for WordPress 6.7

1.3.2 Compatibility Release for WordPress 6.5

Compatibility Release for WordPress 6.5

1.3.1 Compatibility Release for WordPress 6.4

Compatibility Release for WordPress 6.4

1.3.0 Compatibility Release for WordPress 6.3

What's Changed

• Compatibility Release for WordPress 6.3 (tested with RC2 beta) (2023-08-02)
• Change dashboard title to avoid perceived false positive "warning" status #9
• 1.3.0 release notes by @openmindculture in #11

Full Changelog: 1.2.0...1.3.0

1.2.0 Compatibility Release for WordPress 6.2

What's Changed

• Review Refinements 1.0.0 by @openmindculture in #2
• Fix Coding Issues for Release Candidate 4 by @openmindculture in #4
• add WordPress code sniffer by @openmindculture in #6

New Contributors

• @openmindculture made their first contribution in #2

Full Changelog: 1.1.1...1.2.0

1.0.0-rc4 WordPress Code Review Refinements

What's Changed

• Fix Coding Issues for Release Candidate 4 by @openmindculture in #4

Full Changelog: 1.0.0-rc3...1.0.0-rc4

Issues after "improving" the code for release candidate 3 (#2):

Instead of using inline CSS with <<<HEREDOC, and failing to find a proper escape function, I decided to include a CSS file but forgot to use wp_enqueue instead of a regular element to load the external CSS file.

Based on the SonarLint warnings about snake_case namings, I changed the function and variable names, removing prefixes where I thought it safe for a seemingly local function. While those seemed to be correct (how can we know if there is no local version of their linter available for my IDE?), the automatic code sniffer complained about the names where I only removed the underscore between prefix and the rest of the identifier, like openmindcultureWpstatusDashboardWidgets instead of openmindculture_wpstatus_dashboarddidgets. Hopefully openmindculture_wpstatusDashboardWidgets will do (again, how are we to know without a local code sniffer?) and so we will have to disable the SonarLint S100 rule for the whole project.

The code review process could be much easier for both parties if we had a local version of the WordPress code sniffer available. Some of the WordPress coding guidelines seem to contradict general PHP coding styles, like avoiding underscores in function names as suggested by SonarLint, even when JetBrains WordPress support is active in PhpStorm. The only public validation service I am aware of, only validates the readme.txt file. How can I validate my PHP files before submitting my plugins for another code review next time?

1.0.0 Release Candidate 3 after Code Review Refinements

What's Changed

• Review Refinements 1.0.0 by @openmindculture in #2

Fixed

• Incorrect Stable Tag
• Variables and options must be escaped when echo'd. Examples
• Do not use HEREDOC or NOWDOC syntax in your plugins
• fix code style according to SonarLint warnings
• update documentation

Full Changelog: 1.1.1...1.0.0-rc3

1.1.1 Release Candidate with updated description

• Removed restricted words from plugin description and widget footer.
• updated description and documentation

1.1.0 Incompatibility Status (shorter name, new version number)

• Removed restricted word from plugin title.

1.0.0 Initial Release as a WordPress Plugin

update banner collage