IMHO the directory is still very much a work in progress. Having just been through the process of trying to get a plugin listed I came to realise it has a long way to go (and I’ve given up).
There is also the list of numerous irregularities that @anon66243189 has identified and submitted.
I suggest we remove the various links on the website till we have something that is ready to present to public view, or at least put a “beta” tag on the links so people know not to expect too much.
What exactly is the problem with the directory? It’s actually nothing more than a self-hosted Git, or am I wrong because the WordPress directory is also syncronized with GitHub. Is there any way to help, I’d love to have a better plugin and theme directory for ClassicPress.
And Yes, BETA- Links would be a Great Idea <3
The plugin directory was developed simultaneously with the rules/guidelines being formulated so there are now a lot of inconsistencies. At some stage it was decided that you must have a forum account to post a plugin, but some of the early entries don’t do this. Also there are fields for user name and developer names that will take any value, whereas these should be pre-filled from the forum profiles to ensure consistency.
In my case I had a lot of trouble entering information (500 errors everywhere), and now I finally have a plugin apparently published but I am not listed under developers and my plugin is nowhere.
It just seems to me to be very much still a work in progress and I think having official links up makes it look like it is a stable release.
I learned recently that the directory is built with Laravel (unless I misread something). Laravel is a fine platform but I’m not sure why CP chose not to eat their own dogfood, since a functional directory could easily be built with CP, ACF Pro, Relevanssi and some CPTs in about a couple of weeks, and would also have the advantage that more CP developers could work on it.
So, as a webmaster, I prefer Quick & Dirty solutions, why not just make a Git system like WordPress itself has, which ultimately makes it easier for developers to keep their code up to date. Those who can submit plugins get their own subrepo, can fork it on their dev account, develop it further and after testing it, branches. So I’d be for a simple and developer-friendly solution. Sometimes a step back is worth more than 2 steps further towards the dead end.
This was all discussed some time ago.
I have argued for dogfooding many times. It could be applied to (almost?) everything we do. I have yet to be successful. But I live in hope.
We use git already, the directory is merely a directory of „entries“ linking to the respective plugin repo
We use this for two reasons:
—-
Unfortunately i don’t think at this point we can hide it again - we blog posted, we announced, we talked.
Taking it away now is going to be a classic „they aren’t ready“ move and it’s like shooting our own foot.
It’ll take 15 hours to scan each plugin by my calculations.
Done that, we can take down what’s inappropriate and contact + maybe take down unclear ones
Then at least the repo is clean.
So within one week, 2 or 3 people can fix that.
—-
@ozfiddler each error if still experienced has to be reported and fixed with urgency.
We can’t afford error 500 for some weeks.
However since we did indeed use laravel and I personally for example don’t even know where to start when it comes to laravel ….I agree we should have done that with what we all know and that’s cp/php (like the doc site). At least any dev could then debug and even commit things.
But that train has departed. Too late unless we re_start.
Im very much in favour of only using our tools and not using some sophistication that only few do understand, but taking down/hiding the repo at this point is going to hurt us I think more than the work we need to fix it all.
If we hide it it’s just going to take longer because no one will actually think about it anymore
So - let’s gather the issues, list them, make git issues for our laravel folks to fix what is to fix in laravel and I’d be happy to receive help from one or 2 folks who do understand how to install and use wpcs + do know our brand policies and the directory guidelines to scan the remaining (ca 75) plugins.
I already started with that but had to stop as other things came up.
Since we now have an active plugin review - later this step won’t be necessary anymore
Please inbox me if you can help with scanning of code, brand guidelines and directory requirements
Let’s list actual laravel/directory issues each in one new ticket on GitHub? Does that sound good?
If we all pack it tgt by end of next week this all is just a bad memory
I think @anon66243189 is right in saying we should fix and go on.
For a different reason.
Nobody expects that it is perfect from the very start. The directory now is an “open beta” up for testing and refinement. Whereas before was in an alpha stage.
Now we need people using it and giving all the feedback.
And we need to act on it.
Taking it back will mean that we are not ready to work on it, for all our users.
We need to show we are, and that this is a good time for the community to test and report on it, so that we can make it even better.
One feedback that I have is: WordPress allows users to have an account and set their favorite plugins/themes to find them quickly.
I find this feature very useful when using WP since I install a bunch of plugins on every site I build. Is this something that will be included in the future in our directory too?
I can only offer feedback as an user, since I am not a dev.
Another thing, the pagination. When you go from page one to page xxx the page you are on is not highlighted in the numbered pagination at the bottom, so there is no way to know visually on which page I am. I find this disheartening since I am visually impaired and not having such way to define where I am is generally a disaster for me. Another thing, if you scroll to the bottom to click on the pagination links when changing page you will retain the position at the bottom, having to scroll up to see the page and eventually down again to click pagination again.
Another thing that bothers my ocd is that some plugins directly download, others open another page where you need to locate download links…
Then the link should indicate that.
Yes. This I agree.
It would clarify that we need community input to make it overall better and solve the mishaps like the 500 error mentioned above.
If nobody uses it we won’t have any feedback.
So the links should stay there with a way to show it’s a beta.
And for non devs like me there should be a way to report user issues without having to go on GitHub… (If I have time later I am going to post my feedback on GitHub because I know my way around it, but not every user does).
There is no header with something like “ClassicPress directory”.
Maybe this can added with a beta-status message and a “report an issue” link.
There is a link at the bottom for “report issues”. It would be good to have a link to the docs as well.
OK so:
1. Update Menu link and other links that point to the DIR with something like “Plugins (Beta)”?
(I disagree. I say we just fix things asap and renounce the menu/link editing which we would have to edit back in a couple weeks)
2. Add “DOC Link” on footer in DIR?
https://github.com/ClassicPress/directory/issues/5
3. Add Header on DIR that says “ClassicPress directory”?
https://github.com/ClassicPress/directory/issues/4
@ElisabettaCarrara pagination is highlighted, but horrifically grey in grey, so not even I with a eagles sight can see it, actually I had to full-brighten my screen and put on my reading glasses to see that the current page is a tad less dark than the rest. It is also not clickable, so that’s a quick way to know where you are but I agree, CSS needs to change there, thus:
4. Change current active pagination link color to a more recognisable.
https://github.com/ClassicPress/directory/issues/3
I don’t know what you mean whit “when paginating I have to scroll up”
I do not need to scroll on that list, as there are just three rows…
Favourite plugins, is something that is not a breaking issue and also, can and should only be added once we actually push those things to the CP Admin, before that, I do not see how it makes sense to add such thing, since the only users on the directory are developers, and we certainly don’t need to mark plugins as favourites. That’s a “user” thing IMO. Agreed we can offset that to a feature to be added maybe in a year?
@ozfiddler - please let me know if E500 is still happening and if your user/plugin can now be found. If not, I suggest you ping @wadestriebel directly for this rather annoying problem.
No one replied to the ask for help to review the plugins so I assume this means no one yet involved here wants to or can help with this
What I ask thou is that if you have simple User issues to report, make it so that the ones who need to fix it can find the issue quickly and follow up with it in 3 weeks or 3 months time.
that means, a google sheet, a Git Issue (one each issue) or such is greatly appreciated.
Unfortunately topics in general tend to mix opinion and issues, so for example above 4 points needed to be extracted from the above thread. That is suboptimal 
Anyone has anything concise to add that we need to do in order to bring this thing up to speed?
So far we only have real minor issues listed. Where are the major issues? Do we have a concise list of these?
I hear some fields should be required but are not, but I am not sure which precise fields this refers to.
Forum name is one… yet the profile goes to be reviewed manually after submit. So I guess that would be a reason for feedback after review, if the forum user name is missing? Thus we should make it required, but it is not a breaking issue either.
Issue is here to follow up with:
I love your optimism.
Yes. The whole directory is grey on grey.
No, that has been fixed now.
Cool.
I love your optimism.
I know it is a hilarious and unrealistic optimism - but yet, its the only way to move on IMO. We need to believe that things will move fast, and to the best, in the parts it has to. If we do not believe that, we can as well stop even trying, it’s like the difference between believing to be sick, or healthy
No, that has been fixed now.
I still can’t find your plugin or user in the dir.
Are you in touch with Wade for this? I do hope this is just a exception, and not a repeating issue. If it is, it needs even more (urgent) attention.
that said, we likely should gather devs that have laravel experience so they can help Wade. He is alone in this task. That is not to underestimate. The pressure and the time invested in it is huge.
@anon66243189 what I mean about scroll up/down is:
I am on page, I visualize plugins, I scroll to last row and reach page bottom, then I click the pagination to go next page, the page changes but remains on the bottom, so I need to scroll up to see all rows of plugins listed there. And then when I am done I need to scroll down again to click next page on the pagination.
I use Vivaldi browser.
Can this be set in a way that clicking the next page brings you to the top of the page where the first row of plugins is? And can we have a top pagination and a bottom one? I mean, if it was CP I know it was possible. But it’s Laravel and I don’t know if such things are feasible with it.
About the CSS I guess this aspect was left to be dealt with when it was really ready to be implemented in core… Thanks for clarifying that it has indeed an highlight.
About the addition of beta to links, we should have a way to tell people that this is a beta. First round of issues like plugins to be checked/removed is going to be solved in 2/3 weeks time, but this doesn’t make it ready for implementation. It will stay as a beta needing test and feedback until it gets implemented IMHO, so it makes sense to state it is a beta. But it’s only the way I see it.
I will post my feedback on GitHub within tomorrow so it stays in a central place.
About plugin review, I am no dev and I can barely understand PHP, a little better I do with css and html. So I am to little use in that regard. I can however compile a list of plugins based on where they go/what they do when I click download link.
And I can test to see if they work on a fresh CP install.
One that does not work is the elementor experimental fork…
You must use a tiny screen?
As said there is nothing to scroll on my screen. Can you elaborate on what screen you see this?
Mobile?
I will post my feedback on GitHub within tomorrow so it stays in a central place.
great!
About plugin review, I am no dev and I can barely understand PHP, a little better I do with css and html. So I am to little use in that regard. I can however compile a list of plugins based on where they go/what they do when I click download link.
And I can test to see if they work on a fresh CP install.
One that does not work is the elementor experimental fork…
Perfect!!
Know that a “tiny” (or not so tiny?) help is still a help.
For example you can see if the plugin is called “classicpress thing”. That infringes our brandmark. It should be “thing for classicpress”.
These things do not need DEV experience to see. Or, as you state, test where the link goes, or maybe you see that the plugin is only tested up to WP 3.x, or you see that a plugin does not work at all… those things are helpful. As long they are reported in an organised manner (like one git tick each issue or even a simple google table) someone can act on it.
About not being dev… I personally for example, I am a boatbuilder, a bricklayer, and I bought my first computer in 2008. I entered a support team in 2014, because I know 5 languages. I did not even know how to echo a string in PHP. Today, I am confident to write a plugin in PHP for WP or CP. Yet, I did not achieve this magically. It was a process, which starts with “do what you can” and “ask, never be afraid to ask”, and then followed by “I want to learn”.
So… I guess you know what I try to say 
PS this is the table I started to review Plugins/Devs on the dir:
So, if we get a list looking similar to that, with a column explaining what is wrong, this already saves hours and hours of work
Also - a DEV often does not see what a User does see. For a DEV the pagination which is not showing current page is a “non-issue” very often. They are concerned with the amazing query they wrote to make it work. Yet a user doesnt care about that query, they care that it shows what they search for and that they understand it. So if both work hand in hand, then great products are made.
Laptop, if I am not mistaken it’s a 15"… How wide is the screen you are using? And I must say I need 100% zoom or higher just because I wear glasses. I never go under 100%.
I agree on the learning curve…
And if just testing such details with plugins is enough I will do my best to do a readable and organized table out of it so that someone can use it to work on the directory. I may have some hours this week so it’s definitely something I can do.
I’m experiencing the same, using a regular-sized laptop… i think its width is 1366 px…