Use Elixir to create the next Wordpress?

  • Is it a bad idea?
  • Is Elixir the correct tooling?
  • Technical constraints?
  • How to handle the plugins, themes ecosystem? (maybe mix install?)

Thank you for reading :smiley:


Such a platform requires pluggable add-ons. Elixir can achieve that but it’s not trivial, and security can definitely be an issue.


This is not unique to elixir though. Any platform without sandboxing has that problem, including PHP/Wordpress itself.

1 Like

Yep, true. In fact I don’t know of a language/platform that does this well. I still remember people breaking Java’s security subsystem years ago, maybe that was improved in the meantime.

I think, this is the greatest problem.
This is also true if you wanted to program an extensible Ecommerce system, for example. There are some comments about this here in the forum.

1 Like

Yes. Unless we get a hard sandbox for the BEAM VM then I don’t think such efforts will ever go anywhere.

Of course there are other options like just use a Lua engine to program plugins but then the single language paradigm of such platforms goes down the drain and you might as well not use a BEAM language at all.

I am sure there are ways around it but it’s probably too hard to be worth it.

1 Like

Or accept the security implications like many other systems, which provide runtime supplied pluggable functionality.

Yes. I still wouldn’t mind (if it was my job) because Elixir still has a ton of advantages compared to JS or PHP for such projects. But it needs to be said that it’s not at all easy to pull off.

1 Like

I’ve thought about this a lot, and have come to the conclusion that plugins basically destroy the premise of doing this in most languages (not an Elixir thing). It feels like PHP is actually uniquely positioned as the best foundation for a WP-like system.

You could totally build a drop-in plugin system in Elixir, although it would be much more involved because you’d need to compile the plugins and add the compiled source to the application. The code_server process can handle this dynamically, I believe. Then questions like, what would prevent a plugin from overwriting an existing module? The security can of worms is big on this project.

The even harder thing about plugins is that they can completely change the operation of core wordpress operations. So having a pure core separate from the plugins isn’t really applicable in practice. I don’t think you could simply ignore it because the UX depends on having a powerful plugin system that can change the operation of the system. Modifications to wp-theme.php are the bane of any WP developer, but is also quite common because software is hard.


I’m curious why you think PHP is uniquely positioned for such a system? By my understanding PHP has exactly the same issues. Sure there’s compilation, but the beam and elixir have quite nice api around doing that even at runtime. The statefulness of the system means you need to be a bit more diligent with unloading stuff compared to the “load everything from scratch each request” in PHP, but other than that I don’t really see a big difference.

My main reason for this is that everything in PHP is drop-in and evaluated on every request. So you literally just need to put files there and it works. The devil is in the details—it just works in PHP but you’d need to replicate it to have the same effect, and I’m not sure it’s super easy to do. The other thing about it is that PHP files are edited live in pretty much any major WP installation. It’s just a feeling though, I don’t have a ton of empirical evidence here because I haven’t seen it attempted in earnest.

I suppose you could build that type of system in other languages (dealing with compilation as needed, setup files correctly, etc), but I’m not aware of other systems that have replicated this.

In PHP the new code will be loaded in an isolated process instead of being system wide, and you will not be able to redefine a module/class that already exists. This is best to try to run malicious code.

Plus PHP is easier with “one click install” providers I guess. That being said, I find using Luerl for plugins could be very cool and safe, though maybe not very fast.

Thank you for all your responses, it boosted my confidence.

I thought I will list some of the top Wordpress plugins & find-out how to implement it, likely the most of them should be implemented in core, including:

  • Content management: should be like (Drupal, or Strapi) content types; User can define Post, Service, Project, …, & attach field to them
  • Querying, filter data: Ecto Query is a beast
  • The admin dashboard: not many people will use the admin dashboard, so we will keep all the state (Ecto data) in the LiveView socket, so mutations will be very fast; this is a big win
  • Field types: user also can define any field type, this will be validated with json schema (can replace Wordpress ACF Advanced custom field)
  • Products/orders: should be like Spree / Solidus
  • Rich text editor: Slate.js is a wonderful tooling for this (Slate can be serialize into json object), I think it should be handle on client side to reduce comunication between client-server (we later can use LiveView to render rich text object created by Slate)
  • Page builder: A block builder, just a set of some prebuilt component that can be composed
  • Dynamic routes: can be easily customized with Phoenix
  • SEO stuff: should be in core (like Yoast SEO)
  • SEO audit: should be in a separate app in umbrella; can analyze the content using internal (database) or external (send request) query
  • The system will expose an GraphQL endpoint using Absinthe
  • Image compression
    • When user upload an image, we will execute a sharp cli (will be bundled by the app) to generate derived images (argument should be like w_1200, w_1200,h_800 ), if it slow, we can make them communicate via RabbitMQ
  • Theming?
    • In some of my previous project, they were built with Svelte, React, Vue that consume data from GraphQL endpoint and bundled to ESM project, or docker image; managed by version. I see it’s too complicated.
    • Allow user to edit css directly, like some Tailwind editor out there, can be compiled & generate to minimized css
    • LiveView & Surface is evolving, so I thought we can build components using Surface. My try will be create an app for each theme, and call mix install (same for other plugins that haven’t listed above), do we have something like mix uninstall to unload an app?
  • Data Migration

Am I missing something important here? :smiley:
Thank you for reading; :smiley:

1 Like

I’ve spent some time thinking about this and some time going down paths I abandoned.

I have an effort underway which I’ve shared some stuff about in my newsletter. Since I’m aware that a CMS is a massive effort I’m trying to start with foundational libraries and stacking those bricks up over time.

Even on just this forum I’ve seen this idea come up and fall down.

I think Elixir could do great at CMS things but the road to featureful enough is absurd.

Give it a shot if you like. I applaud any effort in that direction but be aware that it is a lot of work.

My view on “solving” the CMS problem is pretty particular and it involves tackling this particular painpoint, among others: Underjord | The WordPress merging problem

For me it begins with making content type creation strong. And going down that route you’ll find out that Ecto schemas really are very compile-time and if you don’t want arbitrary atom proliferation, from code-gen, as a risk that leads to other choices. Can of worms :slight_smile:

I can share more when and if it starts to make sense :slight_smile:


There is a CMS system in itself for many years: Zotonic

However, Zotonic is based on Erlang, which can be extended and customized with your own modules and templates. The template-system is based on erlydtl.

My interest is rather Ecommerce, also for this Elixir would be actually well suited, there are also some companies that use it exactly for this, but just proprietary:

For an open source ecommerce system you would need the possibility to develop plugins, especially to program your own themes for the store.

In Zotonic, for example, you can extend the template’s in a simple way via the blocks as in Django or PHP-Twig.

Zotonic Template’s

Twig-Template’s for Shopware

From time to time I try to figure out how to do this in Phoenix, but unfortunately I haven’t made any progress. Especially if there are other solutions instead of blocks? In such a store system, however, there can be hundreds of blocks, which are very fine-granular (as you can see in the shopware example).

I would be grateful for ideas regarding extensible templates in a nice way.