classicpress / directory Goto Github PK
View Code? Open in Web Editor NEWClassicPress Directory for plugins, themes, and code snippets powered by ClassicPress.
Home Page: https://directory.classicpress.net
License: Other
ClassicPress Directory for plugins, themes, and code snippets powered by ClassicPress.
Home Page: https://directory.classicpress.net
License: Other
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
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.
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.
directory.classicpress.net (https://www.directory.classicpress.net/) has an SSL certificate error, can't access the directory.
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.
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.
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:
We can add a few more but these need to be high-level and not too many. The rest should be reserved for tags.
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.
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.
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?
Right now, code snippets are treated just like plugins/themes:
This brings up several issues:
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.
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.
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
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).
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.
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:
"wp_mail( '[email protected]', 'Test email', 'This is a test.', array('Content-Type: text/html; charset=UTF-8') );" --allow-root
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.
}
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:
Relevanssi works really well so far with testing.
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.
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.
In order to simplify things but also keep everything secure and accessible, here's my proposed deployment workflow:
staging
is the main working branch, which is synced to the staging website. We use it to test changes.staging
branch, you can SSH into the server and git pull
to get the changes.staging
with production
.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.
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.
There are several issues with README.md conversion in terms of styling. Using Update Manager as an example.
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.
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!
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.
We could use register_post_status()
to add new statuses, something like this:
We need to help support developers. If they want to, they should be able to add a donation link. It will be shown:
I've already added text input to the profile page (97aa8ab).
For reference, this is what WordPress shows:
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:
@KTS915 @xxsimoxx So I ran a test using Shortcodes Everywhere plugin as an example and we may have a problem.
Original:
https://github.com/xxsimoxx/codepotent-shortcodes-everywhere/
https://github.com/xxsimoxx/codepotent-shortcodes-everywhere/releases/download/1.1.2/codepotent-shortcodes-everywhere-1.1.2.zip
codepotent-shortcodes-everywhere
Duplicate submitted by me:
https://github.com/viktorix/codepotent-shortcodes-everywhere/
https://github.com/viktorix/codepotent-shortcodes-everywhere/releases/download/1.1.2/codepotent-shortcodes-everywhere-1.1.2.zip
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
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.
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.
If you look at Simone Fioravanti
from the developers page you'll find that Registration Honeypot
is showing twice and Update Manager
is missing.
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?
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
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.