Sometimes the way WP structure of making queries can be a pain in the ass. It works indeed, but most of those who opt for an OOP way may feel disappointed. Luckily, WordPress is still PHP and can be used and manipulated in several ways – which means the MySQL database cane be also accessed by any other script.

Github examples bring experiments using Eloquent or Doctrine for creating a bridge in which entities can be created to access the database. However, that means two things: installing a plugin or creating models and entity classes manually.

Fortunately, another PHP ORM script can help us having all of this arsenal ready to be used from a pocketful of CLI commands. So, in this article, we will show you how to easily produce a database schema file and generating classes from WP DB using Propel ORM.

Installing Propel

Contrary to Doctrine or Eloquent, which ask for intrincated configurations and at least some knowledge on Symfony or Laravel/Lumen, Propel works more as a standalone ORM. Even though some other options like Cycle ORM come to mind, Propel’s mechanism is probably the simplest.

First and foremost, we don’t want those entities or Propel dependencies to necessarily be loaded with WP. So the best option is to create a composer.json file on WP root directory, rather than using wp-content directory.

So, either manually or using composer init command, create a composer.json file in the root directory. Once it is done, just access the CLI on root and require Propel using:

composer require propel/propel

Simple as that. Now, we can already use Propel’s CLI tools, but just in case, let’s test them. If everything worked well, you can list Propel’s commands like this (using the command vendor/bin/propel).

Although most of Propel’s commands are related to newly created databases and migrations, you can also autodiscover the schema for any existing database. In other words: “magic” entity classes can be generated.

Creating the entities

Once Propel is installed, all you need to do is to use its initializer for establishing a connection to the existing database from WordPress. The simpler way is using the command vendor/bin/propel init.

A helper process is then initiated. First, you choose the driver (mysql in this case). Then, the info on the WP database can be entered. Localhost as the server, 3306 as port and your database credentials from wp-config.php in the sequence.

If the connection is successfully created, it asks you whether the database already exists or not. Type “yes” and move forward. The helper will ask you where you want to save the schema.xml file (which includes a profile of the database) and the entity classes (preferably, put them in a separate directory).

If the reversed engineering (generating classes from the existing database) runs ok, you can finally choose a format for Propel’s config file (I prefer using PHP). At the end of the process, you’ll see something like that – so check all info and type “yes” again. And done, it is ready to use.

Reversed engineering was successful – in other words, the entity classes have been generated.

Propel has an extensive and comprehensive documentation, where you can find easy information on how to proceed queries, migrations and so on using the generated classes.

Why using a “WordPress ORM”?

Although WordPress has its own query classes and functions, it hasn’t been initially conceived for heavy DB operations. Throughout the years, WP evolved. However, in terms of dealing with the database, WordPress remained basically the same. Sometimes it is slow while proceeding heavier queries, and there are good reasons for that:

  • Plugins use different mechanisms to access the WP database – not necessarily in the best way.
  • WP hooks – one of the most fantastic tools on WP coding – can also be a problem for queries. They are equally present in the DB processes, and some simple queries might be triggering several other hooked up processes.
  • A lot of plugins create new tables, custom post types, post and user metadata, and as time goes by, tables like wp_posts or wp_postmeta can be full of junk.

Using an ORM may bring some light on functional and slow ways of making queries. Running Propel in parallel, and not loading it using a plugin, might be an useful mechanism to make database migrations, create faster and external queries or even APIs and put some heavier tasks – like importing thousands of posts – independent from WordPress core.

Also, it is a fantastic way for understanding better how WP schema is built and how it works without the CMS script. But taking a look inside one of the entity classes created is maybe a better way of understanding that.

Each table will have classes with getters and setters, filter methods and other helpers to join tables, make queries in the same transaction and more.