Simplify plugin and theme contribution process

[PhrozenByte]

See https://github.com/picocms/picocms.github.io/pull/33#issuecomment-823233631

Maybe we should think about how we want to manage plugins and themes in the future. Obviously I don't have enough time to actually do a code review for plugins. The idea behind this review process was to ensure a basic level of quality and to prevent malicious plugins. However, I feel like that we can't really achieve this anyway. Developers can update their plugins at any time. Furthermore there's our Wiki with yet another list of themes and plugins. So maybe we should abolish this "review required" process and switch to a much simpler process? The question is: How? I feel like the way we present plugins and themes on picocms.org right now isn't really suitable for this, is it?

Feedback is highly appreciated! :heart:

CC @mayamcdougall

[mayamcdougall]

Sorry, this turned into a bit of a brain dump (cough More HR's make it more readable, right?? cough). 😅

I agree that the current solution isn't really ideal, but I'm not really sure how we'd solve it at present.

I feel like some level of review is always going to be required no mater what.

Even if we over-engineered a submission page that "validated" everything for us, generated perfect YML from some text fields, checked and/or cropped image dimensions, validated code, etc etc, there would still need to be a final review of user submitted content. Otherwise we'll check the themes page some day, realize it's just a bunch of explicit images, and wonder "How long has it been like this? 😨".

And for the plugins page, I guess they'd all inject hidden ads for pills or something. 😂 (On a side note, I had to fix this on an acquaintance's Wordpress a while back. The clever malware only displayed its spam if the Referrer URL was from a search engine, so it went completely unnoticed for months on a low-traffic website. 🤦🏻‍♀️)

While I'd like to think I'm just being paranoid, my faith in people is awful low. It could just take one troll to create an endless stream of junk content, and then moderating it would be more effort than the current submission process.

---

And plugins make me even more nervous about the idea. Like, I agree 100% with your past sentiment that having plugins on the Pico website implies that we're endorsing them.

But what could we do? Put a big red disclaimer on the top of the page that says "These Plugins are User Submitted content and are not independently verified by PicoCMS"? I feel like that would only attract abusers.

I feel like bigger projects or companies would simply solve this by inviting users to "Flag" malicious content, but the Pico community is far too small to work like that. Maybe some day if we get a couple hundred more themes and plugins submitted. 😉

At least with the Wiki, most people hopefully understand that a Wiki is user-generated and that they should proceed with a little caution.

I'm rambling at this point, but I don't really have a good solution for this. 🤔

And to be honest, I don't usually review the theme code at all lately. I used to at least try to run them on a testing instance of Pico to make sure they weren't completely broken, but it got kind of tedious. 😒

And even if I reviewed the relatively safe Twig code, I've got no real way to check that some javascript they're pulling in isn't going to start secretly mining Bitcoin (or indeed, like you said, that they don't just modify it later on to be malicious).

---

Man, this is getting more depressing the more I think about it. 😑

Maybe we should have a warning that not all content is vetted. 😩

I feel like the current submission process does act as a good social barrier though. Not as many people would bother submitting malicious things or spam knowing that someone will look at it. Also, the extra effort of submitting a PR itself is a good barrier. If we see any just-opened GitHub accounts, we've got a good indication that something might need more investigating.

But ultimately, the task of verifying everything in perpetuity (woo! big words!) is definitely impossible, so there needs to be a middle ground.

---

Maybe the solution is to address another issue, the Plugins page itself.

I love the theme gallery, and feel it's absolutely necessary for Pico because it shows users, visually, what Pico can accomplish. I can't count the number of times I've clicked away from a project's website because they couldn't show pictures of their software in action. Pico's gallery could always be better with more themes, but at least it's something...

But the Plugins "Gallery" is just garbage. It should never have used the gallery layout. It's hard to read and impossible to actually get any useful information from. There is exactly one plugin with a thumbnail, and it was there from the start. 🤦🏻‍♀️

So... what if the Plugins page... was the Wiki? Either embedded (yuck 🤮), a link (better), or as a static copy of the Wiki text that is (hopefully) automatically generated on update. 🤔

I feel like this idea has some potential, but I'm not sure exactly how you'd want to accomplish it. Maybe there's a way to hook into the wiki updates and run a script that updates the site text to match? Or maybe it'd be better to have some Javascript fetch the wiki contents when the page loads and avoid the need for automation all together?

What are your thoughts on that idea? This would essentially remove "Plugin Submissions" as a thing altogether and just source them from the wiki. (While of course formatting the text to also look nice on the site).

Also, a small discrepancy I've noticed on the site: The Themes page is clearly titled Community Themes, while the Plugins page says Pico Plugins, not something like Community Plugins which would better emphasize that most of them are not maintained by PicoCMS.

---

Okay, done. Just read the last block, it's the important one. 🤦🏻‍♀️😅

[mayamcdougall]

Rough Idea of how the current Wiki content looks with the site's theme. 😉

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in two days if no further activity occurs. Thank you for your contributions! :+1:

[PhrozenByte]

Sorry for the late response... Time's extremely limited lately :unamused:

I don't think that it's even possible to fully automate the submission process with GitHub Pages. I was rather thinking about simplifying it by limiting the review process to a simple "does it work?" approach (just like you do for themes). I don't think that code reviews are feasible right now; thinking about it I'm not even sure whether they serve any real purpose, since we can't prevent malicious plugins and themes anyway. We shouldn't claim something else. However, our website suggests something else right now. This is bad.

Another thing to keep in mind is that with Wiki + Website users might get a wrong impression about how many plugins and themes we have. There should be a single place to get plugins and themes. This can either be our website, or our Wiki, not both. I like your idea with switching to a simple list for plugins (mostly taken from our Wiki, maybe with some additional grouping). The gallery YAML is way to complex. We might switch to a "mixed" approach for themes, too - having the gallery with screenshots and reviewed themes on top, and a list of additional themes (those currently in our Wiki only) on the bottom.

The problem is: Thinking about it I'm not even sure whether I have enough time to even perform simple "does it work?" tests. Since there's no code review required anymore, I'm pretty sure that any experienced Pico user (like yourself :wink: ) can do this. Can you imagine taking responsibility for any submissions, both plugins and themes?

This would allow us to simply the submission process to something we can actually handle. If we can't even support this, we might remove the pages from our website altogether and add links to the Wiki instead :unamused:

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in two days if no further activity occurs. Thank you for your contributions! :+1:

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in two days if no further activity occurs. Thank you for your contributions! :+1:

[PhrozenByte]

So, what do you think @mayamcdougall?

[mayamcdougall]

Sorry, just been a little busy.

The plugin submission process should definitely change, and should probably just go away. I agree that code review is just something that realistically isn't going to happen, for either plugins or themes. And unless we were to somehow recruit a bunch of people overnight, it's probably never going to happen.

I don't really feel confident in reviewing them myself. A lot of the plugins that we get submitted are very niche, and specific to that developer's circumstance (eg, "I made this for myself, and I'm throwing it out there in case others find it useful"). Then there's the fact that plugins, tend not to be "plug-and-play", but require additional setup to make use of. I just don't think it's something I could really commit to. Both for the added complexity and the time.

That being said, with themes, the submission process is easy enough that I don't mind it. It's not hard to fix a few lines of YML for someone when they want to merge it. Even if we didn't make any changes to the current Themes setup, I'd be okay managing it, the way it is now, for the foreseeable future.

Also, as I said in my last comment, I really think having the themes displayed visually is a requirement for the site.

(In fact, if I had a ton of free time, I'd love to port a bunch more simple themes and fill out the gallery. The last one I did, Stellar was pretty fun. 😅 I think I got to "think like a programmer" this time around and really deep-dive on how to best leverage Pico's capabilities. And I still have things I wanted to add to it...)

---

So, I think where I'm at with everything is this:

• For now, Themes can stay a gallery, with a submission process*.
• Plugins should be a list. It just makes more sense that way.
• Plugin "submissions" aren't really viable, so either we:
  • a) Instruct people to just add them to the wiki, then copy the wiki content ourselves** or
  • b) Instruct people to edit the Plugin page itself with their submission and make a PR of that.
• And of course, add a disclaimer to the Plugin page that content is user-submitted and not endorsed by the project.

* If we feel it's necessary, we can also add a disclaimer to the Themes page that content is user-submitted. However, every theme just links to its author's GitHub page, so I feel like it's already somewhat implied that "Hey, these aren't coming from us. Use your own discretion, you've been taken somewhere else on the Internet after all." 😉

* Plugin submissions and wiki edits are so infrequent, that this wouldn't be a huge undertaking even without automation. That being said, the current* state of the wiki page is a little... cluttered, to say the least. I wouldn't be sure where to even begin with sorting it out.

I'm sure there's also plenty of out-of-date content that could be removed, but I also wouldn't really feel comfortable doing it. There's a few too many items with strikethroughs and multiple forks that should probably be sorted out. 😩

It would definitely need cleaning up, but it could be the basis for a new plugins page.

(Also, I was thinking of how we could break up the list a little and thought "Oh, alphabetically!"... right, so the entire list will just appear under the letter "P" 🤦🏻‍♀️)

---

If you like these ideas, I can make the changes on the website sometime (the plugins/themes changes, and also changes to the "contributing" stuff). The biggest struggle for me would be the Plugins list itself.

Let me know if you have some ideas of how you'd want it organized, and what should stay or go.

Because I don't think it can all stay... but I also don't want to hurt any feelings by cutting things just because they might look unmaintained. 🤔😔

(And of course, I'll do the work on my own fork that way we can get the final product polished before making the switch for real.)

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in two days if no further activity occurs. Thank you for your contributions! :+1:

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in two days if no further activity occurs. Thank you for your contributions! :+1:

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in two days if no further activity occurs. Thank you for your contributions! :+1:

[PhrozenByte]

This is probably to most long drawn-out dicussion I've ever had :see_no_evil: My bad, sorry! :unamused:

So, I think where I'm at with everything is this:

• For now, Themes can stay a gallery, with a submission process*.
• Plugins should be a list. It just makes more sense that way.
• Plugin "submissions" aren't really viable, so either we:
  • a) Instruct people to just add them to the wiki, then copy the wiki content ourselves** or
  • b) Instruct people to edit the Plugin page itself with their submission and make a PR of that.
• And of course, add a disclaimer to the Plugin page that content is user-submitted and not endorsed by the project.

Full ACK.

Plugins: A "merge without any checks" approach for plugins is the only really viable solution then I guess. I totally agree that a big disclaimer about plugins being user-submitted and non-curated is a requirement then. Personally I'd rather go for the "pull request" approach than copying the wiki (basically I'd prefer to see the wiki vanish).

I don't think that a plain list of plugins is a good idea, this might get a bit overwhelming (just look at the wiki right now :see_no_evil:). We should at least group plugins by some basic (!) categories. Some short description (just a few words one grasps by just looking at the plugin's README.md) would be reasonable, too. We should also include a "made for Pico X" tag (API_VERSION constant for Pico 2.0+, onX events for Pico 1.0, otherwise Pico 0.x). Maybe we won't actually end up having a plain list, there might be visually better alternatives (maybe something like https://picocms.org/cookbook/? idk...)?

About duplicate and deprecated plugins: Since checking all plugins isn't realistic, we might simply append duplicate plugins to the recommended ones, just as an alternative. This won't require us to actually test the plugins... They all worked at some point, otherwise they wouldn't be in the wiki I guess. Most old plugins should still work due to PicoDeprecated, too.

Themes: Agreed.

I also agree that a gallery is very reasonable for themes. However, does this mean that you want to create a gallery entry for every single theme in the wiki? This looks like a lot of work to me. Don't get me wrong, I'd definitely love to see this happen :+1: Just to make sure we don't talk at cross-purposes here.

If you like these ideas, I can make the changes on the website sometime (the plugins/themes changes, and also changes to the "contributing" stuff). The biggest struggle for me would be the Plugins list itself.

Awesome! :heart: I promise to answer faster now :see_no_evil:

[mayamcdougall]

No worries. I know how it gets. I've been spending all my free time lately working on my home media server, and barely any time on the app I'm supposed to be programming. 😒

Yeah, I liked the PR idea best too. And, I mean, if people are already expected to read about a somewhat complicated Submission process for the current gallery, things can only get easier for them.

I agree that a plain text list of plugins might be overwhelming or get out of hand like the current wiki. I'm not set that it needs to be just plain text on a page, just that it should be overall text-based. There's definitely room to have decent formatting and/or framework around the idea. Some kind of a list, perhaps with categories and/or the ability to filter the list to show less entries.

I'll think about it a little and see if I can come up with a UX that would work well for it.

Also, if your end goal is to get rid of the wiki, I could probably bring myself to make gallery entries for each theme. 😉 (There aren't really that many, and quite a few of them are already in the gallery anyway).

I know you were pointing that out as being an off-topic thing... but it's totally doable.

Anyway, I'll look around and see if I can find any good ideas for a fancier list.

[PhrozenByte]

Great, looking forward to your ideas :+1: :smiley:

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in two days if no further activity occurs. Thank you for your contributions! :+1:

[mayamcdougall]

The text isn't necessarily final, but any thoughts on including a codeblock-style disclaimer on the Themes page (and probably future Plugins)?

Just messing around in the web inspector for a few minutes, but I thought it had some potential. 🤔

Ideally I'd hide it behind some kind of "Important Notice (i)" text, but I really doubt anyone would ever click it if I did. 😂

Also, do you like "community developed", "community contributed", or using both like in the screenshot?

[mayamcdougall]

@PhrozenByte I'd like to make the gallery look a little nicer (and hopefully a little more modern, if I can manage it). It's especially hard to see the white-on-white of some of the plainer themes right now.

Do you like either of these directions:

Rounded w/ Drop Shadow

Border w/ Title

The second one there may have been inspired by the themes page of another CMS...

And yes, the second screenshot is cropped slightly higher to hide the fact that I didn't do the second row. 😂

[PhrozenByte]

I feel like a combination (rounded with drop shadow and title) would be best, especially keeping your idea with a "Ready for use" badge in mind :heart:

By the way: If you feel like the current gallery JS/CSS/HTML is to clumsy, feel free to replace it with something else.

[mayamcdougall]

Huh, I really didn't think you'd go for rounded. 😂

Originally I was set on rounded, but as I kept going, I started to like the titles underneath idea too. I wasn't going to be upset no matter which one you picked. 😉

But together, that might be the winner. I hadn't thought of that.

Putting the titles underneath has really made me feel the shortcomings of the current "overlay" titles / descriptions. I also started to notice this when I was adding themes last time. It's again visually impressive, but not very practical. So I think it's going away in favor of having the titles underneath and some simple "glow" effects when hovering.

I'm not going to replace the gallery yet (mostly since I don't know what I'd replace it with), but any style changes I make should hopefully still carry over if I swap it in the future.

[mayamcdougall]

Since you seem to be online right now... Here's a progress update:

Regular

Hover

Currently trying to dial in the position of the "Learn more" button (technically not a button, but it's styled like one).

Perfectly centered on the thumbnail feels too high (pictured), and centered on the whole tile (thumbnail and label) is too low. I'm thinking I'm just going to have to pick a happy medium that isn't actually "centered". P=

[mayamcdougall]

The Pico "Seal of Approval" and the Pico "Ribbon of Approval".

No actual plans to use either of these for anything, just brainstorming.

In the end, it'll probably be something like a recommended star ⭐, because I don't want them to feel officially "endorsed" by Pico. I'm also having trouble deciding on a criteria for something being either Ready-to-go or Code Free, another tag I thought of. Code Free would just be that this theme doesn't expect you to edit the Twig template to make it your own. But... there's a lot of overlap between the two. 🤦🏻‍♀️

[PhrozenByte]

Looks great so far! :heart:

I'm also having trouble deciding on a criteria for something being either Ready-to-go or Code Free, another tag I thought of. Code Free would just be that this theme doesn't expect you to edit the Twig template to make it your own. But... there's a lot of overlap between the two. 🤦🏻‍♀️

As far as I understood @gelavat right, he was referring to a theme's usage resp. setup, i.e. whether one can simply copy it to the themes folder and regular content files work as expected. Some themes require plugins, some themes use multiple templates and require one to specify a Template first (e.g. clean-blog), some themes require special YAML headers to work proberly, some themes require a special directory structure. Themes with this tag should work out-of-the-box and without any special setup - or: one doesn't need any docs (maybe for advanced features, but not for a themes basic usage).

[mayamcdougall]

Sounds like a pretty good criteria. I think for the most part it's just going to have to be a judgement call on each theme. I think some setup should be allowed as long as its basic. Config options or YAML parameters seem like they'd be okay as long as the ReadMe's are good. I mean, at the very least you have to select a theme in your config, so there's always some setup.

What I've got in mind when I'm thinking about either Ready-to-go or Code Free are the basic one-page themes ported by @BesrourMS and myself. They typically have very minimal configuration using YAML in your index file. So, I feel like this at least qualifies for Code Free if not also Ready-to-go.

Where as I've seen some themes that have options A, B, and C in their YAML, but in order to change X, Y, and Z you have to edit the Twig template. Those would definitely not qualify. (However, there could be some that would maybe meet the criteria with just a simple commit or two 🤔😉).

[mayamcdougall]

Not nearly as flashy, but perhaps a more practical approach. 😉

Would probably want some kind of info button/hover next to the legend to better explain it... but considering it's all just hacked into the code inspector, I haven't done that yet, lol.

[mayamcdougall]

Alright, so, a little bit of a status update here. The styles for the above design are just about done. Take a look here.

Due to the way the original design was done, there were a lot of extra size-specific styles I had to implement. I've tested at the various resolutions, and everything seems good.

The most complicated effect I implemented was a fade out gradient on the titles. If a title runs a little too long for the space available (either because it hits the edge of the tile or it hits the R2G / CF tags section), it fades out instead of clipping.

This was a little overkill, but it was fun to implement (except for having to make it work at all resolutions).

I've also added the rounded corners to all of the Fancybox image viewers. I had to use a slightly hacky workaround for images with a text blurb underneath them.

When I rounded the corners of the image viewer, it made any images with text blocks underneath them also rounded on bottom, which didn't look great.

But I had no way in CSS to know if this text block followed the image. So, after working at it a bit and not finding a good solution, I simply moved the text block up 5px so it overlaps the rounded corners. 😅

I'm not happy about it, but it looks fine and is a lot simpler of a solution than, for example, modifying Fancybox to indicate with a class whether or not there will be a text block following it.

---

So, the styles are done, but the big issue remaining is deciding what Themes should be tagged as either Ready-to-go or Code Free.

Here's more or less where I'm at with it. Looking for any input @PhrozenByte, and @gelavat if you're still interested in helping with this.

Ready-to-go

1) Steps to install should be no more complicated than: 1) Extract Files 2) Set theme in config.yml 3) Configure any additional theme-specific options in config.yml or index.md. 2) Ready-to-go should imply that a theme's "Design" is finished and intended to be used as-is. Anything that describes itself as more of a "starting point" or "barebones" should not be R2G even if it's easy to install. This doesn't discredit themes that intentionally "minimalist" though, as long as they are considered finished and intended for as-is use.

• I'm debating a little on this though, as it seems more like a disqualification for Code Free. As it stands, the two categories feel very similar, with usually one implying the other.

Other Concerns

• Does requiring the use of the Template YML property make a theme too complicated and not R2G?
• Does an old readme (config.php instructions) disqualify R2G? Perhaps "no" if it's only to set your theme, but yes if there are additional parameters?
• Are themes with non-functioning contact forms (where you must supply your own POST handler) considered not R2G? It is realistically out-of-scope to provide this functionality, but we could require it be documented (download this, place it here). That seems more like a trap (and a security issue) for new users though, and I'd rather just see the forms be non-functional for someone who lacks the experience to set it up themselves.
• Originally, creating a Ready-to-go tag felt like it should be for themes that "Went the extra mile" to provide the user with a good experience. I'm not really sure that's where it is right now. Okay, I know that's not where it is right now. What I don't know is what to do about it.
• The concept of having Ready-to-go themes be a kind of "tested and verified" criteria is a good one, however, it goes against the original idea of this thread, simplifying the contribution process.
• So, if making them "tested and verified" is out-of-scope for this, where do we land on it? Should it just be the "three step" installation process above? Or should we put an additional emphasis on ReadMe's having to be of a certain quality? That a theme should at least look easy to install and use, even if we're not going to be able to test them all.

Code Free

1) Everything must be exposed in config.yml or in markdown files. 2) Editing the theme itself must not be encouraged. 3) Theme must be a complete design that stands on its own, not a template or a work-in-progress.

Other Concerns

• Does a poor readme / install experience disqualify CF? If so, this kind of implies that a CF theme will always be both R2G and CF. 🤔
• Is there a better way to separate the R2G criteria from the CF criteria. Usually, if a theme meets one criteria it meets both. Should I just drop the CF idea and stick to only having an R2G tag?

---

Any other thoughts on this project? I'd love to get it merged, but it's not quite there yet.

I might separate and merge just the style bits if we don't get this finalized for a bit, since I think they're worth the update on their own.

What you see right now in my personal fork above has everything tagged as I saw fit. I have some notes on why I didn't label some, so we could work with the ones that just barely didn't make it to get them fixed.

You'll notice though, that everything tagged is tagged as both R2G and CF like I described above. 🤦🏻‍♀️

So that's some food for thought.

---

(Separating this into one final block because it's kind of its own side rant)

A Featured tag might not be a bad thing either. This could maybe bridge the gap of not having a "tested and verified" tag. It could maybe also be a better fit for the original "extra mile" concept I mentioned above.

A theme would have to meet a very high bar for this criteria, and as such, it would probably only be applied to my own themes right now. 🤦🏻‍♀️

And even then, I wouldn't feel confident doing that without some extra testing on them and some small updates.

A Featured theme author would have to be committed to a high quality experience... which is just something I don't see in any of them right now.

I know I think a bit highly of myself here: I think my themes have some of the best documentation on ANY of them. And yet I'm still guilty of the "submit it and forget it" mindset. This wouldn't cut it for a Featured theme. At some point, I might put in the effort to test and revamp my old submissions (and or completely rebuild them). If and when that time comes, I'd consider labeling them as Featured.

If anyone else comes along in the meantime with some submissions they'd want to put that extra level of commitment into, I'd welcome the idea of labeling their work as Featured too.

I think we could really use it, and I think that would be the best fit for @gelavat's concerns as well. But it's just not something we have in the gallery at the moment. 🤷🏻‍♀️

[mayamcdougall]

At the moment, I'm leaning toward getting rid of CF. I do like the extra splash of color (😉), but really, the criteria will probably just be rolled into R2G (eg, a R2G theme must not require or expect a user to code anything).

[PhrozenByte]

Just wanna let you know that I'm currently on vacation and will answer immediately after my return. What I can say from a quick look: The styles look amazing, I love it! :heart:

[mayamcdougall]

Thanks, lol. No worries, and no rush. Enjoy your vacation. Talk to you about it soon. 😉

[PhrozenByte]

Here we go, sorry for the delay :v:

As I said earlier, I really love the new design :heart:

At the moment, I'm leaning toward getting rid of CF. I do like the extra splash of color (:wink:), but really, the criteria will probably just be rolled into R2G (eg, a R2G theme must not require or expect a user to code anything).

I agree. They are just too similar. I furthermore assume that users won't really understand the difference. Users must understand flags at first glance.

---

• Does requiring the use of the Template YML property make a theme too complicated and not R2G?

It depends. Basically all more feature-rich themes require Template headers or something similar to implement their advanced features. However, a theme supporting advanced features shouldn't be disqualified for the R2G flag just because it provides more possibilities (for obvious reasons :smile:).

A very simple test for this is a "sample contents" test: If a theme shows Pico's sample contents (i.e. basic websites with just static content) without additional config, without plugins and without any issues in general, it's very likely a R2G theme (e.g. Clean Blog will fail this test).

• Does an old readme (config.php instructions) disqualify R2G? Perhaps "no" if it's only to set your theme, but yes if there are additional parameters?

R2G themes shouldn't require any additional config to work - except for theme. I'd assume this not to be a real problem, since theme developers usually provide defaults anyway. As soon as a user must edit config.yml except for theme, it's no R2G theme.

Considering config.php I'd prefer to require R2G themes to be fairly recent. config.yml was introduced with Pico 2.0 three years ago. However, I'd assume that a lot of possible R2G themes might loose this flag just because of mentioning config.php (please correct me if I'm wrong with my assumption). Thus I'd say that this should be no requirement.

• Are themes with non-functioning contact forms (where you must supply your own POST handler) considered not R2G? It is realistically out-of-scope to provide this functionality, but we could require it be documented (download this, place it here). That seems more like a trap (and a security issue) for new users though, and I'd rather just see the forms be non-functional for someone who lacks the experience to set it up themselves.

Advanced features which require additional config (like contact forms) should be hidden by default and the theme should still pass the "sample contents" test if advanced features weren't enabled. See above.

The same is true if a theme requires plugins to work: For the R2G flag the theme must pass the "sample contents" test without any of the required plugins installed. For example, some themes require a pagination plugin to work, otherwise they don't show any contents. Such a theme is no R2G theme.

• Originally, creating a Ready-to-go tag felt like it should be for themes that "Went the extra mile" to provide the user with a good experience. I'm not really sure that's where it is right now. Okay, I know that's not where it is right now. What I don't know is what to do about it.

What exactly do you mean by "went the extra mile"? A good documentation?

• So, if making them "tested and verified" is out-of-scope for this, where do we land on it? Should it just be the "three step" installation process above? Or should we put an additional emphasis on ReadMe's having to be of a certain quality? That a theme should at least look easy to install and use, even if we're not going to be able to test them all.

For a R2G flag we definitely need a quick "install & try" test, otherwise it would be impossible to flag themes. However, we won't test any of the advanced feature, nor check a theme's source code. This is still a huge diff effort-wise.

---

Any other thoughts on this project? I'd love to get it merged, but it's not quite there yet.

As soon as you think it's ready for merge we'll merge it :+1:

---

A Featured theme author would have to be committed to a high quality experience... which is just something I don't see in any of them right now.

I agree. This would be great to have (as suggested by @gelavat). However, I'm afraid that this isn't possible right now, because flagging just a single theme as featured feels a bit odd.

I think we could really use it, and I think that would be the best fit for @gelavat's concerns as well. But it's just not something we have in the gallery at the moment. 🤷🏻‍♀️

Some input from @gelavat would be great here :+1:

[mayamcdougall]

I feel like by the end of your comment, you've accidentally made a good case for why CF should exist... but with their roles reversed: with CF being a step down from R2G, not up. Something that's not quite R2G because it requires configuration, but is still intended to be used without coding. 🤔

The sample-contents test sounds like a good idea. This would disqualify a lot of the easy-to-use, one-page themes that have been ported though, since these usually depend on their own supplied content files. I feel like they'd also be a good case for CF. While I was also considering them to be R2G based on their ease-of-use... they do kind of go against the grain and use Pico in perhaps an unexpected way. While easy, that difference in behavior could be confusing to a new user.

By "went the extra mile", I mean a theme who's developer has taken a lot of time to provide a good experience to the user. Good documentation would be a part of this, but also avoiding any other paper-cut like issues. They should really have looked at things from the user's perspective and tried to make things as user-friendly as possible.

(So, the opposite of most of our "I made a thing and threw it over the wall into open source land in case someone finds it useful" themes 😂)

In the end, this concept might apply more to a future, Featured tag. In reference to the original R2G idea though, it meant that such a theme would be so easy and hassle free to set up that a user of any skill level would be guaranteed to have a good time.

So, I think that's the direction I'm going to take. I'll combine your sample-contents test for R2G with this new "downgraded" CF tag and see how it feels.

In general (with CF), I'd just like to do something to promote the ported themes. While it would be great if we had more original themes, the existence of the ported themes does well to showcase that Pico does more than just its barebones Default theme suggests (and the many, many similarly minimalist themes). It can literally produce any level of complexity in design that you could throw in a Twig template... and yet most of what we have to show for it is black text on a white background. 😑

Most of the more design heavy themes are niche, one-page designs though. I guess in the future I'll have to go porting some more "pretty, but basic" designs that'll support Pico's sample-contents. 🤔😂

[PhrozenByte]

I feel like by the end of your comment, you've accidentally made a good case for why CF should exist... but with their roles reversed: with CF being a step down from R2G, not up. Something that's not quite R2G because it requires configuration, but is still intended to be used without coding. :thinking:

I still believe that users won't really understand the difference. Can you estimate how many themes would be flagged with one flag only?

The sample-contents test sounds like a good idea. This would disqualify a lot of the easy-to-use, one-page themes that have been ported though, since these usually depend on their own supplied content files. I feel like they'd also be a good case for CF. While I was also considering them to be R2G based on their ease-of-use... they do kind of go against the grain and use Pico in perhaps an unexpected way. While easy, that difference in behavior could be confusing to a new user.

Hmm... Maybe we could lower this to a "shows the sample content's index.md" test?

In the end, this concept might apply more to a future, Featured tag. In reference to the original R2G idea though, it meant that such a theme would be so easy and hassle free to set up that a user of any skill level would be guaranteed to have a good time.

I agree.

In general (with CF), I'd just like to do something to promote the ported themes. While it would be great if we had more original themes, the existence of the ported themes does well to showcase that Pico does more than just its barebones Default theme suggests (and the many, many similarly minimalist themes). It can literally produce any level of complexity in design that you could throw in a Twig template... and yet most of what we have to show for it is black text on a white background. expressionless

True.

Most of the more design heavy themes are niche, one-page designs though. I guess in the future I'll have to go porting some more "pretty, but basic" designs that'll support Pico's sample-contents. thinkingjoy

I'd love to see this :+1:

[mayamcdougall]

I still believe that users won't really understand the difference.

I've actually been thinking I should look into making some kind of "modal" pop-up that explains it. This would also help if we had more tags (Featured) in the future. Basically just have an (i) icon next to the legend at the top, and clicking on it would present a message box floating over the screen.

Can you estimate how many themes would be flagged with one flag only?

Not without going through them all again. 😅

I can say that it'll probably be a lot less than I have tagged right now.

Hmm... Maybe we could lower this to a "shows the sample content's index.md" test?

I don't think that would help at all. It's usually more all-or-nothing. For the most part, a theme either completely conforms to Pico's "typical" implementation or it does its own thing. And in those cases, even if it technically "displayed" the contents of index.md, it would probably be amongst a broken mess of missing strings and other values that their own index.md should have provided.

I actually think that the sample-contents test is a really good idea. I'm torn about it because it means certain themes I'd have considered "Ready-to-go" won't make the cut just for being different. But, I like the idea enough that I'm willing to accept that they don't really belong under that label due to their differences.

I'd love to see this 👍

Me too. If only I could find the time. 😣 😂

[mayamcdougall]

I merged the style changes for now. We can work out the tagging stuff going forward.

I kind of want to sarcastically rename this issue something like "Redesign Galleries and tag themes with some sort of consistency... I guess." The original point of "Simplify plugin and theme contribution process" seems like it got forgotten pretty early on. 🤔😂

[mayamcdougall]

Since the Plugins have titles underneath them now too, I got curious about what the would happen if I just started jamming some more text into the Isotope items.

I'm not suggesting we do it this way... but I honestly expected it to break a lot more. I mean, these styles are horrible and hacky... but... it's not awful...

Maybe 2x2?

I wanted to find a new javascript bit for this, but for the time being... I might actually be able to make a "list" out of Isotope. 🤔

At least as a temporary measure, would something like this be an improvement?

I could make a serious attempt at it if you're interested.

Maybe add in a little flair... (This one's photoshopped though. 😅)

[PhrozenByte]

Can you estimate how many themes would be flagged with one flag only?

Not without going through them all again. :sweat_smile:

I can say that it'll probably be a lot less than I have tagged right now.

Ok, so maybe for a later Featured tag :see_no_evil:

Hmm... Maybe we could lower this to a "shows the sample content's index.md" test?

I don't think that would help at all. It's usually more all-or-nothing. For the most part, a theme either completely conforms to Pico's "typical" implementation or it does its own thing. And in those cases, even if it technically "displayed" the contents of index.md, it would probably be amongst a broken mess of missing strings and other values that their own index.md should have provided.

I actually think that the sample-contents test is a really good idea. I'm torn about it because it means certain themes I'd have considered "Ready-to-go" won't make the cut just for being different. But, I like the idea enough that I'm willing to accept that they don't really belong under that label due to their differences.

Ok, then let's do it this way :+1:

I merged the style changes for now. We can work out the tagging stuff going forward.

:heart:

I kind of want to sarcastically rename this issue something like "Redesign Galleries and tag themes with some sort of consistency... I guess." The original point of "Simplify plugin and theme contribution process" seems like it got forgotten pretty early on. thinkingjoy

Go ahead :+1:

At least as a temporary measure, would something like this be an improvement?

I could make a serious attempt at it if you're interested.

Maybe add in a little flair...

Definitely an improvement (a rather big one tbh :see_no_evil:)! :+1: I really like the direction you're going here, looking forward to it

[gelavat]

Hi all. Sorry for that long delay.

I appreciate your comments and concerns about all this subject!

First I will answer some questions:

Does a poor readme / install experience disqualify CF? If so, this kind of implies that a CF theme will always be both R2G and CF. 🤔

Personally I think yes. The main thing for me that has to be correct is the readme.md file. It can be as complicated as it wants for that theme, no problems as long as by following the "Installation" section of the readme.md, we come up with a working theme. For me this is the biggest criteria. Because when we try and follow everything and it doesn't work, then we enter into posting issues, waiting for answers that never comes, etc.. and this is the worst as it also overloads the team, and will be completely avoided with that solution. We really need someone having tested the "Installation" process from readme.me and corrected it if it fails.

So basically I would say that a theme is R2G as soon as someone has tested it successfully, and that all images and everything works fine.

Is there a better way to separate the R2G criteria from the CF criteria. Usually, if a theme meets one criteria it meets both. Should I just drop the CF idea and stick to only having an R2G tag?

Personally I think that having the CF and R2G is too much of details. I would stick with just R2G, it is enough I think. It is really what the user wants in my opinion. He just wants to know if the theme he selects will be working out "of the box", and by that I mean following the "Installation" section and the "Customization" section to change the texts and adapt it to his needs. So the criteria for an R2G flag for me would be that those both sections would be clear enough to be able to be installed properly, tested by someone else than the editor of the theme (possibly someone of the pico team), and also that the Customization instructions are completely clear so that he knows exactly how to change everything he needs to change, especially texts and images, logos, etc..

Considering config.php I'd prefer to require R2G themes to be fairly recent. config.yml was introduced with Pico 2.0 three years ago. However, I'd assume that a lot of possible R2G themes might loose this flag just because of mentioning config.php (please correct me if I'm wrong with my assumption). Thus I'd say that this should be no requirement.

I also agree that the theme needs to be ready with config.yml to be R2G flagged. That is really important because new users will always get the latest Pico version, which is using this. So config.php style themes would not be R2G as it wouldn't be possible to install them with the current version.

Are themes with non-functioning contact forms (where you must supply your own POST handler) considered not R2G? It is realistically out-of-scope to provide this functionality, but we could require it be documented (download this, place it here). That seems more like a trap (and a security issue) for new users though, and I'd rather just see the forms be non-functional for someone who lacks the experience to set it up themselves.

I think that as long as the documentation, hence the "Customization" section of the readme.md file, is well done and explains how to set your own POST or whatever information to be able to set it up properly, then it is fine and R2G. The aim is that this form needs to be usable by the user. If it is there, then it means that he can set it up properly, even though it needs some more technical knowledge, this doesn't matter, he will be able to figure this out through the doc.

The same is true if a theme requires plugins to work: For the R2G flag the theme must pass the "sample contents" test without any of the required plugins installed. For example, some themes require a pagination plugin to work, otherwise they don't show any contents. Such a theme is no R2G theme.

On this I do not totally agree. Personally I would see that this is still an R2G theme, as long as in the doc it is written what plugin to install and in the right order of the "Installation" section of the readme.md file. E.g.:

1. Backup your "contents" directory
2. Install the "pagination" plugin (with link to it and maybe link to the doc)
3. next step...

--

Regarding the "Featured" flag, I think that Maya is probably right, it is maybe not really needed. It would discriminate the other themes, and hence it is not so fair. I am not absolutely willing to have this flag, but the best looking ones could still be having this "Featured" flag if it seems convenient. For me it doesn't matter in the end if it doesn't exist. The idea of this was just that there would be some minimal themes that would have been tested by the Pico team so that we are sure that we can install them properly. And if something fails with a new version of Pico, then the Pico team would fix those 4-5 themes so that they work with the new version immediately of very quickly. Maybe the "Supported" flag would be more appropriate.

But Maya's idea of the R2G flag seems very good to me, congratulations Maya! I like this idea. It will really do what I need I think. And going with that, then the solution would be to put all "R2G" themes ordered and put first in the list of themes on the website. After all of them are displayed, then the other ones non-R2G would be shown, but people will know that they will enter in some troubles if they use them and will have to take time to understand it, ask, fix, post pull requests, etc... Depending on his level, he will then just take one that is R2G flagged, which will be the case of 95% of the users.

So to summarize, for me the R2G flag should be assigned to any theme that has the "Installation" section and "Customization" section fully described in the readme.md file, in a good and clear manner, whatever complexity it takes to install it or customize it., and tested successfully. The user will be able to follow all steps of those sections and will be happy in the end because it will be working. Posting a pull request of the readme.md would be the solution in most cases as all themes usually work in the end, when we know what to change and how. This is what I will be trying to do with some other themes.

Question for me: what is the "sample-contents", I didn't get what it is really?

Thanks.

[mayamcdougall]

Question for me: what is the "sample-contents", I didn't get what it is really?

The sample contents that display when you load Pico without a content folder. It defaults to showing a couple pages of sample content that explain how to use Pico.

And going with that, then the solution would be to put all "R2G" themes ordered and put first in the list of themes on the website. After all of them are displayed, then the other ones non-R2G would be shown

@PhrozenByte, what are your thoughts on this? Personally, I think labeling them is good enough and that they don't need to be brought to the top of the list. Maybe if "Featured" themes became a thing, they could be at the top, but even then I think I'm leaning toward keeping it alphabetical for "fairness".

If you also think they belong at the top, I could probably make it happen by iterating over the gallery items twice (once for R2G and once for all the others). It'd be hacky at best, but it's not impossible.

My current plan is just to have a "Ready-to-go" category along the top that you could filter by.

[PhrozenByte]

Personally I think yes. The main thing for me that has to be correct is the readme.md file. It can be as complicated as it wants for that theme, no problems as long as by following the "Installation" section of the readme.md, we come up with a working theme.

Maybe an "either or"? It's either as simple as changing the theme in Pico's config.yml and the theme shows Pico's sample contents, or the theme's README.md provides clearly structured, easy to understand and easy to follow install instructions. However, I feel like that there aren't a lot of themes to pass the latter...

@gelavat: We might need some help here, since we both kinda suffer from tunnel vision here :wink:

So config.php style themes would not be R2G as it wouldn't be possible to install them with the current version.

Just to make this clear: One can still install themes written for Pico 0.X and Pico 1.0 (i.e. with config.php in mind). Users can even create a config.php, it will still work. However, I agree that if we go for the "either or" concept mentioned above, referencing (just) config.php should be a no-go for themes that require configuration.

Question for me: what is the "sample-contents", I didn't get what it is really?

What Maya said. Plus: Check Pico's content-sample folder.

And going with that, then the solution would be to put all "R2G" themes ordered and put first in the list of themes on the website. After all of them are displayed, then the other ones non-R2G would be shown

@PhrozenByte, what are your thoughts on this? Personally, I think labeling them is good enough and that they don't need to be brought to the top of the list. Maybe if "Featured" themes became a thing, they could be at the top, but even then I think I'm leaning toward keeping it alphabetical for "fairness".

I'm fine with both solutions. Your choice :+1: If you rather prefer not to change the order, how about making the "Ready-to-go"-category more visible?

---

Another thing: Maybe we should also add a "Pico CMS for Nextcloud" tag for themes that work with Nextcloud. A lot of themes have issues due to Nextcloud's stricter handling of external resources...

[mayamcdougall]

Surprise merge! https://github.com/picocms/picocms.github.io/pull/50 (lol)

Haven't done anything toward getting themes tagged yet. That's still on my todo list.

We do now have tagging support on Plugins as well though. Are there any that should be tagged? (Perhaps "Official" if there are any you think you'd want to endorse). (Edit: I forgot there's already an "Official" category, so I guess I meant, would you like to see them tagged as well?)

The Wiki plugins will still need to be sifted through and sorted out, since they're a mess. But at least this is one (big, overdue) step in the right direction. 😉

Edit2: Also, I think some changes are needed on the information popup box, when you click on them, but that wasn't really in the scope of what I was doing for this mini-project.

[gelavat]

Maybe an "either or"? It's either as simple as changing the theme in Pico's config.yml and the theme shows Pico's sample contents, or the theme's README.md provides clearly structured, easy to understand and easy to follow install instructions. However, I feel like that there aren't a lot of themes to pass the latter... @gelavat: We might need some help here, since we both kinda suffer from tunnel vision here 😉

It seems to me that even if it is as simple as changing the theme in Pico's config.yml file, this instruction still needs to be shown in the "Installation" instructions of the readme.md file. Because the user might not be reading the Pico's doc (I know, very bad, but everyone does so...). So a reminder in the installation instruction would make it for all. This would settle the Installation instruction to always end up with a working theme, no matter if it is simple or not to change it. So the installation instruction would be as simple as:

• Edit the config.yml file and replace the 'theme:' line by 'theme: ".

And also: regarding the "content-sample", the installation instruction should always state to backup the current "content" directory and remove all files in it and replace the directory with the "content-sample". This way, people can directly work on their files to pass to the customization section of the readme.md file. They can then merge the files if they need it, but at least they will have a working and stable theme. And when they do this process, they are able to merge files properly (or just replace the ones needed) because they have already seen a working version on their side.

Basically, the readme.md file needs to indicate everything for a basic user so that he can see his new theme working.

Just to make this clear: One can still install themes written for Pico 0.X and Pico 1.0 (i.e. with config.php in mind). Users can even create a config.php, it will still work. However, I agree that if we go for the "either or" concept mentioned above, referencing (just) config.php should be a no-go for themes that require configuration.

That's good to know. In this case, if this is the only difference between Pico 0.X and 1.0, maybe it could be handled this way: In the readme.md installation instruction, there would always be noted two sub-sections: Pico 0.X: Change the 'so and so theme:' line in the config.php file to 'so and so'. Pico 1.X: Change the 'theme:' line in the config.yml file to 'theme: '

This way, they would all be ready to go, if at least the rest of the readme.md installation and customization sections are well and thouroughly documented for a working installation of the theme. What about that? This way the old/new config is no longer a discrimination, but only the way the doc is done. But then the theme's doc needs to be tested with both old and new versions of Pico.

---

More generally, the idea I had about the 'featured' or 'supported' tags, that now becomes the 'Ready-to-go' tag, was this: Having a little list of a few 3-5 themes that are endorsed by the Pico's team. This means that if there is a new version of Pico, the team will have tested it against those endorsed themes before doing a release. As it was properly stated by @PhrozenByte once, it would be far too long for the Pico team to check the new pico release against all themes. Hence I think it would be very wise to do this. This way, anyone is able to take one of those themes of this list and would be sure that it will work without any issue. Especially if he tries to install a theme and it doesn't work even with the installation instructions, then he can take one of this list and it will work. And if it doesn't work, then it will most probably mean to him that there is a hosting company issue, maybe he doesn't have the proper php version installed, or any other component is missing. This helps A LOT in finding issues when installing any CMS.

Also, we still have a problem: The 'ready-to-go' tag still suffers from my initial thought: it is only ready-to-go for the pico version at one point of time, which is now, because there is no new pico version. But as soon as there will be a new pico version that has some critical changes, some themes might not work again and the 'ready-to-go' tag will no longer be valid. This is what that tag as made to fight against, but we see that it is not working fully. Under wordpress, they handle this issue this way: as soon as we want to install a plugin that has not been tested for the current installed version of wordpress, a message is displayed before the installation stating this: "This plugin has not been tested for your current version of wordpress. There might be issues using it" (or something like that). This is a very good way to show that all plugins or themes are compatible by default, but nobody tested it with the latest version, and until one does the test, this message will remain. This is why I had the idea of showing "verified with pico V1.0" rather than just 'verified' or 'ready-to-go' which basically means the same. And 'verified' in this case of wordpress means quite clearly that it has been verified against basic functionality (not privacy concerns or something else), and should be also the case for pico.

So I think going back to 'verified' would be better, and a hover over it would show what version it was verified for. This also means that there would need to be a database telling what theme has what pico version tested. It is quite a lot of work I know. But this is why this little list of endorsed themes would be necessary, so that you would do that just for this list of themes, which is much much shorter to do than all themes.

I would call this list with and 'endorsed' tag, which would be the very first ones shown on the themes list. It is very important so that people know which one is certain to be working, because you endorse it and they find them at the very top. And if one of your endorsed themes has its creators not answering due to an issue, you would engage to do a fork of it and fixing yourself, or simply remove it from the list and take another.

I think that this is the way to go if we want to have satisfied new comers, and minimizing the impact of pico team's load, it would be the best trade off.

It is basically my initial suggestion, even though I might have described it wrongly, I am sorry for that.

[mayamcdougall]

Okay, so, here's the thing. There's a bit of a disconnect between what you want to see here, and what's actually within our resources to accomplish and sustain. I've tried to convey this already, but our resources are very limited and any time spent on Pico is time we've volunteered, time that we've effectively donated to Pico instead of spending it on other things.

The original point of this thread was a discussion on how to make this more sustainable, as things were falling behind and not getting addressed in a timely fashion. Obviously, this discussion has tangented a lot from that original discussion, which is fine(!), I just want you to keep that in mind when I seem a little unsympathetic to ideas that would require a very large commitment.

I feel bad that I keep shooting down ideas, I do, but unfortunately they're just not realistic in our current situation. Without several additional, regular contributors committed to testing and tagging themes (and plugins), it's just not something sustainable. Sure, I could make the effort to do it right now. It would take a good number of hours to test everything, but I could probably do it over the course of a few days... But I can't commit to that as an ongoing process. I can't promise having that extra time to volunteer in the future on it. So, when I'm trying to decide how to proceed with this, that's the mindset I'm looking at it from. What can I do now that will be beneficial, but won't require an ongoing, endless commitment.

I really hope you don't take this personally. We do appreciate the ideas. And I hate to be such a "downer" about them, but I also don't like making hollow commitments that I know I can't follow through with in the long-term.

I've mentioned before, but the idea of ongoing testing of themes is a little unnecessary. Pico is stable and there are no plans at present to introduce any breaking changes. In fact, @PhrozenByte has made it a point to never break things, by including backwards-compatibility for literally every change he's made over the years (like that comment above about adding a config.php to modern Pico). Having a "verified with" setup just doesn't seem like it would bring enough to the table to justify the ongoing effort.

I do think that some work should be done to update the documentation of themes, especially those with older install instructions. As I've said before, I can't make any promises about them, since it's someone else's content, but I do think it's probably worth limiting the "Ready-to-Go" themes as only those with modern instructions.

I might even try to work with some developers, down the line, to get their themes updated a bit. This might just amount to me forking and updating it for them, but either way it would be nice to see it happen.

If we ever have any officially "endorsed" themes though... It's probably going to be a matter of me writing and maintaining them specifically so that Pico can have some "Official" themes. We just do not have much contribution these days, and I don't see too many old authors being on board with extra maintenance of their long forgotten contributions.

That being said, maybe in the future we can suggest to new contributors that if they'd be willing to commit to ongoing maintenance, we'd tag their theme in our gallery. Maybe even come up with a set of guidelines specifically for featured themes. Overall though, that's going to be a project for later on.

[gelavat]

But it seems to me that my proposal is wrongly understood: I am not suggesting more work but less work. Having only 3 themes to handle is much less efforts than about 20. This is what my optimization suggests. Hence you would just have 3 themes to basically "endorse", which means that each time a new pico version is released only these 3 themes would be needed to be tested against. I think it is not a big effort, because you will anyways need to do this exercise in the process of testing the new version, so you can directly take the "endorsed" ones. And for the other themes, it is a bit like your "ready-to-go" idea, except that it would merely be called "verified", so that in case there is a new version, we can directly put the "verified for V1.0" version in case there is a V1.1. That is quite quick to do on the website. You can even leave the "R2G" tag, and maybe also mention "R2G for V1.0" afterwards when needed, it is just that "verified" is probably more appropriate.

So not a work overload, a work reduction is suggested here. And at the same time, a benefit of 3 themes that the user will be sure they work out of the box, on top of other "R2G" or "verified" tagged ones if one has time to do so, but it is less important in my opinion even though it is also very good to have.

[mayamcdougall]

But it seems to me that my proposal is wrongly understood: I am not suggesting more work but less work

Your proposal is being understood just fine. What you don't seem to be getting here is that I'm not comparing what you suggested before with what you're suggesting now, I'm comparing what you've suggested at any point to how things are now.

Right now, there is no testing of themes. It's unfortunate, but that's how it is. Someone makes a submission, I check to make sure their Markdown isn't going to break the website and that their images are the right size. I glance at their GitHub repo to make sure there's nothing crazy going on there. I say "tyvm for your contribution" and merge their submission.

Anything beyond that is extra. The work I plan to do this week sorting out and tagging the themes, that's extra work that I wouldn't otherwise be doing. But, I think it's a good idea, so I'm going to put in the time to make it happen.

The difference is, it's extra one time work. Once I do it, it'll be done. It won't need maintenance or ongoing attention.

Your proposal involves ongoing work. A small amount, sure, but still ongoing work. The person who will be stuck doing that work would be me. Whether it's 3 themes I'm checking for compatibility or 20 themes, it's still an extra commitment over what I'm doing right now.

And I've explained, again and again, that there isn't a need to verify themes against Pico versions. You seem to be ignoring this for some reason.

You've been very very focused on your idea. No, "Ready-to-Go" is not the same thing as your idea. It's a compromise that better matches something I'd already wanted to do. It is something that sounds more manageable to me, the person who would be responsible for doing the work.

Also, my "Featured" idea for the future does match your idea a bit more closely. It's another compromise though, with the main difference being that the responsibility of ensuring compatibility would be on the theme author and not us. And even if I end up being the theme author in this hypothetical scenario, it would be a commitment made by choice about my own code, and not being responsible for the work of others. I've said above that I do think it would be good for Pico to have some dedicated, "Featured" themes that offer a great experience for new users. This is probably something that I'll work on in the future. But if and when that happens, it'll be my own code that I'll be dedicating myself to supporting. And I'd still welcome others to do the same with their themes.

I'm sorry that I don't like your idea. That's my opinion. As I've said, it's not a bad idea, and it's certainly valid feedback! I just don't feel like it fits the reality of our current situation. No matter how many times you ignore my explanation on this and explain your idea again, it's not going to make me like it any more, and I've already told you why.

I don't like that this situation feels more confrontational after every comment. I try to keep things as friendly and professional as I can, but it seems like no matter how many times I say "No", you just repeat the same suggestion. And yes, I know you're suggesting fewer themes this time, but the fact that you're suggesting it at all feels like you've pretty much ignored any of my own feedback on the idea. 😔

I've given my reasons for disagreeing with it, and I'm getting tired of going in circles about it. 👎🏻

Later this week, I should have the themes tagged and I'll be looking for feedback on them. You're welcome to provide feedback on what you think should or shouldn't make the cut, etc. As long as this feedback isn't "Put a verified with Pico v X.0 tag on it", I'll be happy to take it under consideration. 😕 Edit: This line in particular should have been removed long before I posted this comment. I'm sorry. 😔

[gelavat]

Well, I am still happy that I could provide my idea on this, I think in most details possible and with most described arguments, this was important for me as a user of this nice Pico CMS.

[PhrozenByte]

First of all, I'm very sure we're all here to improve things, so even though we don't have to agree on every topic, please all keep in mind that we're here for a good purpose. All of us (*all*) are participating in their spare time. Spare time is very precious, so I'd like to thank all of you for your work, improvements, suggestions and given opinions on this topic :heart: I really love to see where we're getting in the course of this long-running discussion. In my opinion it's a huge improvement, even though not every suggestion is viable right now.

---

@mayamcdougall

We do now have tagging support on Plugins as well though. Are there any that should be tagged? (Perhaps "Official" if there are any you think you'd want to endorse). (Edit: I forgot there's already an "Official" category, so I guess I meant, would you like to see them tagged as well?)

I like the idea having a "Official" tag. Since you're planning to add a "Ready-to-go" category for themes, I'd say we could do the same for plugins (just with "Official" instead of "Ready-to-go")?

I might even try to work with some developers, down the line, to get their themes updated a bit. This might just amount to me forking and updating it for them, but either way it would be nice to see it happen.

:heart:

I've said above that I do think it would be good for Pico to have some dedicated, "Featured" themes that offer a great experience for new users. This is probably something that I'll work on in the future. But if and when that happens, it'll be my own code that I'll be dedicating myself to supporting. And I'd still welcome others to do the same with their themes.

:heart: :heart:

---

@gelavat

It seems to me that even if it is as simple as changing the theme in Pico's config.yml file, this instruction still needs to be shown in the "Installation" instructions of the readme.md file.

I agree. However, since it's the same for all themes, it should be in Pico's docs, too. It's already mentioned there, but the docs need improvement in general. But this is different topic...

And also: regarding the "content-sample", the installation instruction should always state to backup the current "content" directory and remove all files in it and replace the directory with the "content-sample".

As discussed earlier, some themes don't really work with Pico's sample contents, including single-page portfolio themes. For these themes one must follow the install instructions and/or use the sample contents provided by the theme.

The 'ready-to-go' tag still suffers from my initial thought: it is only ready-to-go for the pico version at one point of time, which is now, because there is no new pico version. But as soon as there will be a new pico version that has some critical changes, some themes might not work again and the 'ready-to-go' tag will no longer be valid.

Since we preserve backwards compatibility in usually all matter this shouldn't be a real problem. If a theme was a R2G theme for Pico 2.1, it will be for Pico 3.0, too. A theme developer can still provide "tested with" information in the theme's README.md though.

Besides, as explained by Maya, we simply don't have the necessary workpower for a "Featured" (or endorsed, or "Tested with", etc.) tag.

Well, I am still happy that I could provide my idea on this, I think in most details possible and with most described arguments, this was important for me as a user of this nice Pico CMS.

As said earlier, thank you very much for your input! :heart: It's very appreciated.

[mayamcdougall]

@gelavat, I want to apologize, again. My previous reply was too hot-headed, and although I tried to rein it in by the end, it was still a bit more aggressive than it should have been. 😔

I guess my main complaint here is that it feels like @PhrozenByte and I are having one discussion in this thread while you're having another. We go back and forth a bit on ideas... and it feels like you've just been jumping in where you left off instead of following the larger discussion.

Not necessarily the case, I know, it's just felt like that to me.

To me, your messages have been coming off in a bit of a presumptuous tone. A sort of "You should do this because I said so", self-important tone. I realize this is probably all in my head, and just part of the shortcomings of communicating over text. You seem well meaning, but for some reason your messages feel more arrogant to me than perhaps they should.

I'm going to try to do a little better about this going forward. I'm not very good at social interactions to begin with, and the last year-and-a-half in the real world haven't exactly done much to help with that. 😓

Please don't take any of my feedback too personally. 😒

[gelavat]

Hello @mayamcdougall . Thank you for that it's nice. I am sorry if I entered the discussion with an off-topic discussion. I have read the previous threads at least. For the "should", maybe this is just because I was asked to provide my thoughts about it. So maybe it seemed a bit presumptuous due to that. But maybe I triggered some control behaviour thought with this, I cannot tell if this is real or not, I would have to introspect myself about that. Sometimes I might mix up roles, because I am also a project manager for some projects so I have to tell people the "you should", which is in fact an order. Here the same term might not fully express what it is really like behind, either just a "it would be good" or "it is really something missing" or an order. So that is probably a bit confusing anyways in the language used. In any case, as you say the shortcomings of the communication through text only are really huge in my experience, so that is definitely not helping. And knowing people always helps a lot too, to better understand the person and what he/she means. 😅

I've said above that I do think it would be good for Pico to have some dedicated, "Featured" themes that offer a great experience for new users. This is probably something that I'll work on in the future. But if and when that happens, it'll be my own code that I'll be dedicating myself to supporting. And I'd still welcome others to do the same with their themes.

I think this is very satisfactory for me and in any case the current improvement with the R2G is arealdy big step, thanks for that Maya 👍

@PhrozenByte you are welcome for the input. Thanks all for this discussion which surely explores all possibilities that are available regarding that matter.

[mayamcdougall]

I just noticed that the rounded corners on Fullview images in the gallery disappear while the carousel rotates between images. 🤦🏻‍♀️ 😖

Hopefully I remember to fix that sometime.