classicpress / directory

ClassicPress Directory for plugins, themes, and code snippets powered by ClassicPress.

ClassicPress: The CMS for Creators. Stable. Lightweight. Instantly Familiar.

ClassicPress is a community-led open source content management system for creators. It is a fork of WordPress 6.2 that preserves the TinyMCE classic editor as the default option. It is half the size of WordPress, contains less bloat improving performance, and has no block editor (Gutenberg/Full Site Editing).

For more information, see:

• The official ClassicPress website ›
• The ClassicPress documentation ›
• The ClassicPress governance ›
• Suggest features ›

Contributions

This project exists thanks to all the people who contribute and who have contributed in the past, whether as part of the long history of thousands of contributions to WordPress from many different people, or as contributions to ClassicPress itself.

Would you like to help? Here is how you can start ›

Sponsors

Corporate sponsors that believe in ClassicPress. Become a sponsor › All donations are tax-deductible in the United States.

Financial Contributors

Support the ClassicPress project by making a donation › All donations are tax-deductible in the United States.

Individuals

Organizations

directory's Issues

Default to non-empty tab on developer's profile

Profiles will default to Plugins tab, which is not an issue for plugin developers but it is an issue for theme developers. Here's an example:
https://staging-directory.classicpress.net/developers/benlumia007/

We should consider defaulting to a non-empty tab if plugin tab is empty. We could use the new tab counts to add a conditional check.

A nice user-centric way to solve this would be to add an option for developer to select default tab for their profile. Although defaulting to a non-empty tab will suffice.

Add WordPress.org repository as a source

This issue is created to continue the discussion started in the forum about adding WordPress.org repository as a source.

If we simply treat it as a repository source, regardless of its rules, it shouldn't be a problem adding it to the directory. It is developer's choice to use WordPress.org instead of a Git-based source. It is also developers responsibility to follow WP repos rules to stay listed. If WordPress closes the plugin/theme, API no longer returns any data and ClassicPress directory would suspend such plugin/theme pending a review.

For this integration to work, WordPress.org API must be used similarly to GitHub API. For example:
https://api.wordpress.org/plugins/info/1.0/wordpress-seo.json

The API returns the necessary data for the directory to do its job:

• download_link - provides URL to a zip file with the latest version.
• description - can be used as a fallback for the item's description, similarly to how fallback works with README.md in the repository.

Plugins/themes would still need to follow all the requirements and rules to be listed in the directory, this includes passing CPCS. Listing in WordPress repository doesn't guarantee listing in ClassicPress directory.

The update process would be handled through the directory as we have a new process being put in place to default to CP directory. If Update URI is empty and Requires CP is set, ClassicPress core will default to use directory for updates. So there should be no issues.

Important to remember: A WordPress plugin installed through original WP core integration will default to use CP directory for updates because it will have Requires CP set.

This could lead to WP repo integration removal from CP core, if WP plugins/themes begin to get listed in the directory.

This is only a discussion right now, open to feedback.

Align download/more info links to the bottom of the card

Right now, all cards have equal heights and descriptions of various lengths. This pushes download/more info links up and down, it's not uniform. There is no consistency.

I'd like to propose aligning them to the bottom of the card with a few HTML/CSS changes to make them look unform and consistent. You can see an example of one in the screenshot above.

One additional suggestion, we should truncate text better to make it more consistent. Maybe even using CSS to hide text to keep it consistent to 3-4 lines.

Allow developers to manage categories/tags

Right now, developers can select categories/tags during initial submission. If they need to change it for some reason, there's no way to do it on their own. For now, we can tell them to message us and we will make the change.

We should consider in the future an option that allows them to manage this themselves. We could add a simple "Manage" button next to "Update Download Link" button and offer a simple form (maybe as a modal) to change categories or tags.

Add donation link

We need to help support developers. If they want to, they should be able to add a donation link. It will be shown:

• profile page
• individual plugin page
• individual theme page

I've already added text input to the profile page (97aa8ab).

For reference, this is what WordPress shows:

TODO

• Add donation link to individual pages
• Add donation link to dev profile page

Proposed deployment workflow

In order to simplify things but also keep everything secure and accessible, here's my proposed deployment workflow:

1. staging is the main working branch, which is synced to the staging website. We use it to test changes.
2. When you need to test changes in the staging branch, you can SSH into the server and git pull to get the changes.
3. When everything is ready and needs to be deployed, create a PR to merge staging with production.
4. At this point git pull in the right directory will sync production branch on the server. production branch is protected.

We may automate step 4 using GitHub Actions to deploy code automatically once changes are made to the production branch. This will expedite the process and can also help reduce access to sensitive server credentials.

Display CHANGELOG.md or changelog.txt if present

This is for future consideration. If the plugin/theme zip file includes CHANGELOG.md or changelog.txt, we should parse it and show it on the plugin/theme page. It's very helpful in WP repo or any software, we should take advantage of it and display it to give users helpful information.

I don't think we need tabs, we could do something as simple as:

or something like this:

And it could open a modal (which is already built-in) or it could hide README.md and display changelog (sort of like tabs).

Form to accept plugin/theme reports

For users to report plugins/themes, we need a form similar to contact form that users can use. It should accept a valid slug in addition to the reporter's details. Validating slug could help reduce spam. The form should pre-fill fields from URL parameters, so we can link from plugin/theme pages and possibly from inside CP admin.

Explore API Data for Core Integration

Explore what data CP site send to WP.org for plugins, and how WP.org responds.

Then compare to the CP Directory API endpoint to verify we have the same data available.

CP Directory Plugin Endpoints:

• https://directory.classicpress.net/api/plugins
• https://directory.classicpress.net/api/plugins/classic-commerce

Excessive 2FA notification emails sent to admins

Describe the bug
A user set up 2FA and as admin I received 67 duplicate emails. The Email Log only lists this email once.

To Reproduce
Steps to reproduce the behavior:

1. A user sets up 2FA
2. As an admin, check your inbox

Expected behavior
Only one email should be sent.

Screenshots

Hide empty tabs on developer profiles

We should consider hiding empty tabs on developer profiles.

For example, plugins and themes would be hidden in this example:

Notice: The new version is missing a Requires CP header.

While updating README.md for the plugins, I noticed we're getting a lot of notices for missing Requires CP header. A lot of the plugins are missing the required headers.

What would be the best course of action? Contact developers and ask them to update plugins to include required headers?

Plugins showing/not showing in REST API

https://staging-directory.classicpress.net/wp-json/wp/v2/plugins?byslug=under-construction
This one should work but return an empty array.
https://staging-directory.classicpress.net/wp-json/wp/v2/plugins/?byslug=azrcrv-smtp
This works.
https://staging-directory.classicpress.net/wp-json/wp/v2/plugins/?byslug=codepotent-update-manager
This works. But should not as it’s not already published.

Can't reproduce the same behavior in my testing site:
https://dir.educatorecinofilo.dog/wp-json/wp/v2/plugins?byslug=doit
This is set as pending and it’s not showing.

Empty dropdown in search form

Describe the bug
An empty select dropdown in plugins search form.

To Reproduce
Steps to reproduce the behavior:

1. Go to Plugins page and look at the search form

Expected behavior
No empty dropdowns.

Screenshots

Download URL redirect for privacy and download counter

Is your feature request related to a problem? Please describe.
Right now the download URL for the plugins/themes is a direct GitHub link. Whenever we integrate this into core, each ClassicPress website downloading a plugin/theme will be logged by GitHub (Microsoft). This poses a potential privacy issue.

Describe the solution you'd like
We need to set up a download URL that's basically a redirect to the GitHub download URL, but it doesn't contain any personal website information to be logged by GitHub. So we protect users' privacy.

While we set this up, we should add a simple download counter to keep track of plugin/theme downloads. A simple counter without any personal website details. Each request to download plugin/theme would increment the counter by 1. This will help ClassicPress and developers better understand how many downloads their items have.

So if the download URL is:
https://github.com/azurecurve/azrcrv-taxonomy-index/releases/download/v1.2.3/azrcrv-taxonomy-index.zip

The directory would replace https://github.com with something like this:
https://directory.classicpress.net/download/azurecurve/azrcrv-taxonomy-index/releases/download/v1.2.3/azrcrv-taxonomy-index.zip

Display code snippets on the page with a code highlighter

Right now, code snippets are treated just like plugins/themes:

1. They require a repo with releases and zip files
2. You can only download code snippet using the zip file

This brings up several issues:

• You can't copy/paste code snippets
• New users might end up trying to install zip file as a plugin

As discussed, Gists might pose a security risk. So what I think might work best is being able to store code snippets in the directory and display them with a code highlighter plugin. An example of this is Classic Commerce website:
https://classiccommerce.cc/docs/snippets/add-a-back-to-shop-button-on-product-page/

Possibly use highlightjs.org

We should ask the user to specify language: PHP, HTML, CSS, JS, TEXT.

Also, if user decides to edit already published code snippet it should go back into review queue.

Reducing faceted search complexity

While testing search, I realized we give users too many options and they don't work well together in their current form. Categories don't work with themes, tags only work with snippets, etc. And it's really not that important. Categories and tags are for browsing, there's no need to offer them in search. At least not right now.

Here's what I'm working on to improve search:

1. Using Relevanssi plugin (compatible with 4.9) to improve search indexing and index API slug (this fixes issue 36). We control what gets indexed and we can also track search queries to see what people are searching for (anonymously).
2. Reduce search fields to text input and post type dropdown.
3. Search results need to indicate what items are what with a label when searched for All Software.

Relevanssi works really well so far with testing.

Add "last updated" date to API data

One important aspect of finding a plugin/theme is how long ago they were updated. We need to track that date, ideally, release date from the GitHub and make sure API data contains that date. This way we can add "Last updated" to plugins/themes inside admin.

Different categories for themes

Looking at the categories, they are specific to plugins. They are not relevant to themes. We should consider changing category dropdown if theme is selected and present relevant categories. A simple list to start:

• Business
• E-commerce
• Blog
• Portfolio
• Photography
• News
• Other

We can add a few more but these need to be high-level and not too many. The rest should be reserved for tags.

Check what it means to switch plugin repo

If we implement our own plugin repo and remove WP repo, all current installs will stop getting updates from WP

we know that there has been and there is a practice of using WP plugins in cp
Thus perhaps “a bundled” repo would need to be analyzed?

right now many sites miss updates from plugins they use which aren’t anymore “compatible” with cp
Removing WP repo at all will also remove updates for those who are actually compatible

"Plugin description" section title

I noticed that "Plugin Description" is used across plugins, themes, and snippets. We should either change it to "Description" or make it conditional so it changes to "Theme Description", "Snippet Description, etc. based on the CPT.

Plugins and Themes mirrors

In order to prevent plugins/themes from disappearing if a developer decides to delete their repos, we need to have a backup. We started the plugins mirror. I'm trying to see if I can get access to it. If not, we'll start with a new org.

Should we have one org for plugins/themes, or have a separate org for plugins mirror and themes mirror?

We need to figure out a way to automate the process, so the directory can trigger creation and updates to the mirrors.

Add developer's display name to the cards

We should include developer's display name in each card to give proper credit and visibility. It should be hyperlinked to developer's profile.

Update Download Link button doesn't show an error if plugin/theme missing required headers

While testing, I noticed that plugins that are missing required headers can still be updated with a success message:

The PHP notice is logged, but it seems there are no error messages for the developer.

Notice: The new version is missing a Requires CP header.
in public_html/wp-content/mu-plugins/download-links.php on line 357

We should display an error message when the developer clicks "Update Download Link" and reject an update. Otherwise, it may update to a new version with missing headers.

Notices generated by WP-CLI commands

Describe the bug
When using WP-CLI commands, they can generate PHP notices since certain things are not available in CLI.

[18-Nov-2022 15:58:43 UTC] PHP Notice:  Trying to get property 'display_name' of non-object in /public_html/wp-content/plugins/kts-email-logs/email-logs.php on line 34
[18-Nov-2022 15:58:43 UTC] PHP Notice:  Undefined index: SERVER_NAME in /public_html/wp-includes/pluggable.php on line 366

This is a not a major issue, since WP-CLI won't be used often.

To Reproduce
Steps to reproduce the behavior:

1. Log in to SSH to use WP-CLI
2. Go to web root directory (public_html)
3. Run "wp_mail( '[email protected]', 'Test email', 'This is a test.', array('Content-Type: text/html; charset=UTF-8') );" --allow-root
4. The notices will be displayed in terminal and logged to debug.log
5. They do prevent emails from being sent.

Expected behavior
No notices. Emails go through sent from WP-CLI.

Additional context
The problem is you can't get $user = get_user_by( 'email', $args['to'] ); in CLI, there's no user logged in. Maybe add a condition to check for WP-CLI environment and if true set an admin user, maybe ID 1, as a default WP-CLI user.

if ( defined( 'WP_CLI' ) && WP_CLI ) {
    // Do WP-CLI specific things.
}

Identical repo slug issue

@KTS915 @xxsimoxx So I ran a test using Shortcodes Everywhere plugin as an example and we may have a problem.

Original:

• Repo: https://github.com/xxsimoxx/codepotent-shortcodes-everywhere/
• Download URL: https://github.com/xxsimoxx/codepotent-shortcodes-everywhere/releases/download/1.1.2/codepotent-shortcodes-everywhere-1.1.2.zip
• Slug: codepotent-shortcodes-everywhere

Duplicate submitted by me:

• Repo: https://github.com/viktorix/codepotent-shortcodes-everywhere/
• Download URL: https://github.com/viktorix/codepotent-shortcodes-everywhere/releases/download/1.1.2/codepotent-shortcodes-everywhere-1.1.2.zip
• Slug: codepotent-shortcodes-everywhere-1.1.2

As you can see, the directory generated a slug based on the zip file name which includes the version number with periods.

Can we generate our own slug using org and repo slug? For example, my duplicate plugin viktorix/codepotent-shortcodes-everywhere would be viktorix-codepotent-shortcodes-everywhere.

In addition, since my duplicate plugin's name is also Shortcodes Everywhere, the CPT slug is shortcodes-everywhere-2. That -2 isn't going to look good. This touches on issue #36. I think we need to improve the slug generation for CPTs too. What if we used API slug from above for CPT slug too? Save us any future trouble. Or even append it with CPT ID or random numbers.

Instead of:
https://staging-directory.classicpress.net/plugins/shortcodes-everywhere-2/

It would be:
https://staging-directory.classicpress.net/plugins/viktorix-shortcodes-everywhere/

You can see meta data for my duplicate plugin here:
https://staging-directory.classicpress.net/wp-admin/post.php?post=2013&action=edit

A plugin is not showing in developer list, another is duplicated

If you look at Simone Fioravanti from the developers page you'll find that Registration Honeypot is showing twice and Update Manager is missing.

Featured plugins/themes on the homepage

Had an idea for showing featured plugins/themes on the homepage without bias.

We can randomly select 4 plugins and 4 themes once a week, cache IDs for a week, and display them on the homepage. So they rotate once a week, randomly selected, and everything is automatic.

Make "Software Links" easier to see

One feedback I heard so far is that it took the user a minute to figure out that "Software Links" is where he can access his plugins. We should simplify this and make each link into their own menu items instead of hiding them in a dropdown. There's nothing else in the toolbar, so we have space for them. Something like this:

What do you think?

SSL certificate error on directory.classicpress.net

directory.classicpress.net (https://www.directory.classicpress.net/) has an SSL certificate error, can't access the directory.

README.md conversion doesn't fallback to readme.txt

Creating an issue to track this bug. With the new GitHub Markdown API integration, directory doesn't fallback to readme.txt. Instead, it finds the first available README.md. In one example, it found README.md inside vendor directory.

We need to limit search for README.md to the root folder of the zip file. If it's not found, it should fallback to readme.txt if present.

Note, we did not test conversion of readme.txt using GitHub Markdown API. Need to test it to see how good it is.

README.md styling issues

There are several issues with README.md conversion in terms of styling. Using Update Manager as an example.

• https://github.com/xxsimoxx/codepotent-update-manager/
• Not published yet: https://staging-directory.classicpress.net/?post_type=plugin&p=1079&preview=true

Issues

1. Code blocks need to be displayed correctly using <pre> tags. Directory styles <code> blocks though.
   

2. Anchor links need to be removed or converted to directory's own anchor links.
   

3. Minor encoding issues.
   

Metadata for GitHub

So i found out that when I was working on my own GitHub communication using API for my own personal site. I found that the Last Updated has an issue where it sometimes trying to retrieved information, it will display 54 years ago! Please see the following

Please see if we can either fix this or set a check if the response to the API has limited or timeout!

Create custom statuses for plugins/themes

As discussed in Slack, it might be a good idea to create some custom statuses to track lifecycle of a plugin/theme and expose status in the API requests that can help notify users of suspended/closed plugins.

• Draft - submitted, pending review
• Publish - review approved
• Suspended - suspended for various reasons
• Closed - closed/deleted for various reasons

We could use register_post_status() to add new statuses, something like this:

Uncaught Error: Class 'ZipArchive' not found

Executing the new wp dir update --id=xx command throws an error.

Fatal error: Uncaught Error: Class 'ZipArchive' not found in /public_html/wp-content/mu-plugins/download-links.php:224
Stack trace:
#0 /public_html/wp-content/plugins/dir-cli/dir-cli.php(82): kts_maybe_update()
#1 [internal function]: XXSimoXX\dir\Dir->update()
#2 phar:///usr/local/bin/wp/vendor/wp-cli/wp-cli/php/WP_CLI/Dispatcher/CommandFactory.php(100): call_user_func()
#3 [internal function]: WP_CLI\Dispatcher\CommandFactory::WP_CLI\Dispatcher\{closure}()
#4 phar:///usr/local/bin/wp/vendor/wp-cli/wp-cli/php/WP_CLI/Dispatcher/Subcommand.php(491): call_user_func()
#5 phar:///usr/local/bin/wp/vendor/wp-cli/wp-cli/php/WP_CLI/Runner.php(419): WP_CLI\Dispatcher\Subcommand->invoke()
#6 phar:///usr/local/bin/wp/vendor/wp-cli/wp-cli/php/WP_CLI/Runner.php(442): WP_CLI\Runner->run_command()
#7 phar:///usr/local/bin/wp/vendor/wp-cli/wp-cli/php/WP_CLI/Runner.php(1256): WP_CLI\Runner->run_command_and_exit()
#8 phar:///usr/local/bin/wp in /public_html/wp-content/mu-plugins/download-links.php on line 224

GitHub slugs and directory slugs

I noticed that directory post slugs are generated by the post title as it normally would, but the actual slug used in the API is based on the repo slug:
https://staging-directory.classicpress.net/plugins/smtp/

"meta": {
"current_version": "2.1.0",
"git_provider": "github",
"requires_cp": "1",
"download_link": "https://github.com/azurecurve/azrcrv-smtp/releases/download/v2.1.0/azrcrv-smtp.zip",
"requires_php": "7.4",
"slug": "azrcrv-smtp",
"developer_name": "azurecurve",
"category_names": "Tools",
"category_slugs": "tools"
}

Should we use the actual slug in the URL too? A reviewer could verify this during review process when publishing software.

Make search text input required

I noticed if search form is submitted without any search queries, it takes user to a rather broken archive/blog page:
https://staging-directory.classicpress.net/?post_types=plugin,theme,snippet

We should make text input required, so there's no change user will be sent to the archive/blog page.

Define what fields have to be required in forms

Currently it seems not all fields that we expect are required in the form
One of those fields is the "Forum Account" field in the form

We shall add here the list of fields that are expected and should be required. Then, we need to check if they are required indeed and if not, make them required.