"Piestingtal.Source" - 100 Plugins/Themes for ClassicPress

Hello ClassicPress friends

I have been using ClassicPress for 2 years now, during which time I have accumulated an assortment of ClassicPress compatible plugins. I am now pleased to make this range available to you. As soon as I’ve added all the plugins there, it will be around 100 plugins and themes. Unfortunately they are all in German at the moment and I am only a single developer teaching myself to code. I am happy about everyone who would like to contribute, e.g. with translations, code snippets, etc.
Highlights: Online shop based on the source code of MarketPress, BrainPress - formerly CoursePress, memberships - formerly Membership2. And above all: loads of multisite plugins.

You can find this GitHub repo HERE.

Would you like to participate in “Psource”? Write to me, I would like to invite you to my team - let’s make ClassicPress even better together with a huge range of free (and rarely paid) plugins and themes!


It’s nice to share, but, this does raise some serious questions.

  • Are you maintaining the plugins for security?
  • If a security issue comes up, can you address it expeditiously?
  • Can you push an update out to the users?

If the answer to all these questions is “yes”, then by all means…

If the answer to any of these questions is “no”, this is a bad idea that will put the ClassicPress community at elevated risk of using outdated, unmaintained, or insecure plugins.

1 Like

Your questions are quite wise and justified.

Of course, I maintain the plugins, I use them productively myself. - However, I am currently a lone warrior, the GitHub Repo serves the OpenSource idea, therefore there are only full versions of almost all plugins without PRO options, paywalls, etc. So every single line of code can be seen by the online community and anyone who wants it can also participate in the development of his favorite plugins. I’ll mention it again, I’m a beginner at coding, I teach it myself with a lack of alternatives and learn every day and try to update all plugins regularly. ALL plugins come with an updater, including an auto-update function, without an extra dashboard and the like, we can update a normal WordPress plugin.

I am pleased that you take it as seriously as I do, safety and user-friendliness are paramount. I hope I can learn something from you and you are welcome in the team if you want to take a plugin under your wing.


Thanks for clarifying what you’re doing. :+1: We (meaning the ClassicPress community) do take security pretty seriously and the safety of users (inasmuch as it can be) is always a concern. It’s good to hear that you’re also taking it seriously.

As long as they’re not zombie plugins (ie, no attention or updates,) it doesn’t seem like it will be a problem. If you make any changes to the code, though, it won’t be in sync with the originals and any updates will wipe out your (new) plugin unless the actual slug is changed. Of course, if the slug is changed, then it is no longer connected with the WP repo and the updateability is gone.

Which raises another question…

Why maintain this repo if these plugins are all freely available? It seems like a lot of work, but, I’m not sure I’m seeing the benefit of putting these plugins in a dedicated repo simply for storage purposes. Have you considered just creating a curated list, rather than the time/effort of creating and keeping a whole repo updated with the latest code? Or, am I missing the point of what you’re doing?

1 Like

I like the friendly atmosphere here in the forum. So the answer is pretty simple … It started with the rolling out from Gutenberg and almost all of the WPMUDEV plugins would be no longer supported. From One Day to the Other… However, I have been working on many projects over the years and sometimes there are hardly any practicable alternatives, especially for special multi-site solutions. At the same time, WordPress became less and less manageable through the Gutenberg Editor and I switched to ClassicPress. And I looked at the many plugins that WPMUDEV no longer wanted to maintain and started teaching myself PhP and JS (I’ve always been good at CSS, after all, that’s often needed in web design) because the error logs spammed me through outdated code . And now, after 2 years of working on it, I want to make them available to the community and let them participate. I think ClassicPress deserves to have a great, community-driven up-and-coming coder scene. After all, it was WordPress with Gutenberg that made many young coders desperate due to many missteps by Automattic. ClassicPress offers new opportunities for a fresh generation of web developers for a ClassicPress own plugin / theme repo and who knows, space for new livelihoods and talents. I see it more as a kind of gift to the community, why are we panting for plugins and themes that are constantly being developed for a WordPress that is alien to us, I just want to provide ideas with this range of themes and plugins and appeal to a German-speaking scene , which is often hindered by the language barrier. For many, English is often a hurdle to learn about plugin / theme development thanks to the poor school policy.
As you can see, my motives are varied, but not malicious.


I think you misread my question and concern. You didn’t mention what benefit this effort provides which is what I’m wondering.

To reiterate: my primary concern is adding unattended plugins to the ecosystem. This is dangerous. If you change anything in the plugins, they’re no longer in sync with the originals and/or they won’t be in the update loop. This leads to zombie plugins, which leads to problems.

It sounds like you haven’t fully considered the implications of this and I’d recommend getting on top of that before putting a bunch of effort into it. A curated list is a much better way to go for this.

The vast majority of plugins at WPMUDEV were poorly coded, buggy, and unreliable – nothing you would want to “learn” from. I predicted they would give up on all those plugins by 2020. They pretty much did. The plugins cultivated a very poor reputation and that’s just not a good way to get people to sign up. IMO, the WPMUDEV plugins were gimmicky and not an overall positive addition to the ecosystem.

1 Like

So you don’t have to worry about update loops and the like, as far as I have the whole thing under control.

You can argue about meaningfulness and quality, but the repos are open to improve it. For my part, I cannot say anything bad about the work of the plugins, they have been working smoothly for me for 9 years, which I cannot say from many other attempts at alternatives, apart from PRO neccessary fees at horrendous fees.
As I said, we can continue to run after plugins that are becoming more and more incompatible, or we can try to get a little breath of fresh air into the previous range in order to inspire young talent and new talents for ClassicPress.

I also foresaw that these plugins will no longer be supported, don’t worry, but for a different reason. At the beginning, like most of them, they experimented a lot and then concentrated on a few that were easy to commercialize. And the “little shit” wasn’t worth it when they grew. Now they also belong to the commercialized WordPress elite. Nevertheless, it was a shame because these niche plugins include very powerful multisite solutions and some things that are no longer GDPR-compliant these days because API there, API here, plugins are often only buttons for external services such as chats, newsletters, etc. There are simply no alternatives in the WordPress market.


It sounds like a valiant effort.

Wishing you good luck! :+1:

This is a huge effort! I wish I could understand more about it, but I don’t speak German. But I can see you have an e-commerce plugin and a forum plugin in there. Are these forks of other programs we might be familiar with?

The range of plugins can also be seen here: https://n3rds.work/psource_kategorien/psource-plugins/

I am curious to know, how do you handle updates? I can see you are calling a file called plugin-update-checker.php - is this something you have written yourself? Does it use the same update process as CP/WP.

I think this project could have a lot of potential for CP users. Pinging @fwolf to get him to take a look.


I use https://github.com/YahnisElsts/plugin-update-checker, the easiest way to make a own Plugin Update Server. I load the zip file in my Update-Directory, and the plugin-update-checker.php checks if there is a higher Version on the Update-Server. Its pretty the same Method how WordPress self makes Plugin-Updates. And you have the full controll over every Plugin, have a API, can see how often installed, etc. Very nice Tool, i have a Fork and have a Rebrand (in Progress) to “Piestingtal.Source”. I think ClassicPress should have to this function inkluded for its own Directory, maybe as a Option to Switch from WordPress Plugins to ClassicPress Plugins.

Make a Look, its OpenSource - Maybe a Solution for the ClassicPress Directory?

1 Like

Thanks. I’m not sure if we even knew about that one. Looks like it handles it invisibly…

From the users’ perspective, it works just like with plugins and themes hosted on WordPress.org. The update checker uses the default upgrade UI that is familiar to most WordPress users.

1 Like

Just a tiny reminder that when it comes to “dead plugins/zombie plugins”, we probably should look at our own repo first.

The list of plugins that should be gone or at least revised is already shared with the relevant department, however, it should never have come to this point.
That is our official repo, and if a private user provides even a thousand “dead” plugins, it is none of our business to worry about the state of that repo. It is however our business (or should be) to clean up our own repo.
Looking at the last issue with CC updates which seems to come from like 3 different locations, if I read it right… we really do not have to teach others how to do it, because we seemingly can’t keep track of our own things properly.

Not an attack, but a firm reminder that before we ask the neighbour to mob their yard, we have to mob our own.