My dislike of WordPress is no secret. I look down on its mess of a code base, and advise anyone with any technical knowhow whatsoever against using it. But I don’t just bash it for the sake of bashing, I bash it in the hopes that someone who knows what they’re doing will pick up the baton one day and continue the popularity race in a more logical, sensible pace. Any attempt to fix the mess WP presents us with day in day out is, in my book, a good one.

我不喜欢WordPress并不是秘密。 我看不起它的代码基础混乱，并建议任何具有任何技术知识的人反对使用它。 但是我不只是为了扑朔迷离，而是扑朔迷离，希望有一个知道自己在做什么的人有一天会拿起接力棒，并以更合乎逻辑，明智的步伐继续进行人气竞赛。 在我的书中，任何修复混乱的WP的尝试每天都会给我们带来好处。

Not too long ago, we heard of a new project on the horizon called Themosis, a “framework for WordPress developers”. In this piece, we’ll try and see what Themosis is, how to get started using it, and we’ll take a look at an example project built with it – the example provided by Themosis themselves.

对于熟悉“框架”一词的任何人，尤其是在PHP的上下文中，这听起来可能令人困惑。 WP是否已经装满了我们不需要的东西？ 框架通常不是建立在一组简约的原理和解耦的组件上，还是建立在它们之上的类似于WordPress的复杂应用程序，而不是相反吗？ 嗯，是。

Themosis isn’t a framework in the full sense of the word as you know it. Instead, it’s an API that ties into WP on a level required to make it easier to develop in – but doesn’t necessarily make it lighter. Themosis is a set of APIs that you use to create WordPress components in a modern-PHP format with namespaces, classes, anonymous functions and Composer support.

就您所知，Themosis不是一个完整的框架。 相反，它是一个与WP绑定的API，它在使之易于开发的水平上是必需的，但不一定使它更轻便。 Themosis是一组API，可用于以现代PHP格式创建具有名称空间，类，匿名函数和Composer支持的WordPress组件。

Themosis is, quite literally, an MVC powered Laravel-ish WP plugin itself that’s used to write other plugins. It also has its own router so you can define routes Laravel-style, and its own templating engine – Scout – that’s similar to what we’re used to in Laravel and Phalcon – with some added extras for built in WordPress support. For example, the template loop:

实际上，Themosis是一个由MVC驱动的Laravel-ish WP插件本身，用于编写其他插件。 它还具有自己的路由器，因此您可以定义Laravel样式的路由，以及其自己的模板引擎– Scout –与我们在Laravel和Phalcon中使用的模板引擎类似–并添加了一些额外的内置WordPress支持功能。 例如，模板循环：

uses WP API to get to the data it requires, and the class is designed only to be used with loops for underlying WP content.

使用WP API来获取所需的数据，并且类仅设计用于基础WP内容的循环。

正在安装 (Installing)

You install Themosis by using Composer and having the WP command line tool installed. Then, when a Composer project is created for Themosis, the latest version of WP is pulled alongside it, so all you have to do is run the standard install script for WP. After that, you can begin developing with Themosis.

您可以通过使用Composer并安装WP命令行工具来安装Themosis。 然后，在为Themosis创建Composer项目时，将WP的最新版本移到它旁边，因此您所要做的就是运行WP的标准安装脚本。 之后，您可以开始使用Themosis开发。

You can follow their installation instructions to get the first instance up and running, though perhaps it’s best if you experiment on the example project first (see below).

您可以按照他们的安装说明来启动和运行第一个实例，但是如果最好先对示例项目进行试验，则最好(请参见下文)。

Themosis offer an example of an app on their website – a bookstore app.

Themosis提供了其网站上的一个应用程序示例- 书店应用程序 。

尝试一下 (Trying it out)

To try it out, you can use this Quick Tip to get a Homestead Improved box up and running. Then just register a new site with:

要试用，可以使用此快速提示来启动并运行Homestead Improvementd盒。 然后只需注册一个新站点：

Of course, don’t forget to add the alias to your host’s file as described in the Homestead Improved Quick Tip.

当然，不要忘记按照Homestead改进的快速提示中的说明，将别名添加到主机的文件中。

Clone the repository with , and visit in your host’s browser to get to the installation procedure.

使用克隆存储库，并在主机的浏览器中访问来获取安装过程。

Go through it, and follow the rest of the instructions here. Now you can play around as much as you want without worrying about breaking something – should something go wrong, we can just rebuild the VM and repeat the process.

仔细阅读，并按照此处的其余说明进行操作。 现在，您可以随心所欲地玩游戏，而不必担心损坏某些东西–如果出现问题，我们可以重建VM并重复该过程。

Once installed as per instructions, you can give the app a go.

在这一点上，这并不令人印象深刻–可以将任何WP网站配置为外观和工作方式如下。 但是，我注意到两个关键点：

1. We got it to run fairly quickly, it was a real no-hassle job. 我们让它运行得相当快，这是一项真正的轻松工作。
2. It’s pretty fast. In fact, it doesn’t perform nearly as slow as I would have expected, Themosis having an extra layer or two to go through to get to the underlying WP API. 非常快。 实际上，它的执行速度并没有我预期的那么慢，Themosis还需要经过一到两层才能到达底层WP API。

What about the code, though? What does that look like?

那代码呢？ 看起来像什么？

代码 (The Code)

You can check out the code on the bookstore’s repository: https://github.com/themosis/bookstore. Let’s see what we can discern. Like I said above, Themosis is actually a plugin, so we need to look for the bookstore’s code among the plugins:

打开它，我们可以找到三个主要子文件夹。 包含由Themosis驱动的WP层的逻辑， 包含Themosis本身的来源(如果仔细查看它们，将会发现与其他更流行的框架的类名和文件夹结构有着惊人的相似性)，我们都知道 -Composer所购内容的去向。

Regarding the actual quality of the code, while certain aspects of it are, most definitely, modern and up to today’s standards (namespaces, classes) and all of it is beautifully documented with return types, parameters and the whole nine yards, there are (and I say this fully aware that I’m nitpicking) some primitive relics as well, like the line used for preventing direct access to PHP scripts, or closing PHP tags at the end of PHP files (unnecessary).

关于代码的实际质量，尽管它的某些方面最肯定是现代的并且符合当今的标准(命名空间，类)，并且所有代码都精美地记录了返回类型，参数和整个九码，但仍有(我说这完全意识到我也在挑剔一些原始文物，例如 该行用于防止直接访问PHP脚本，或在PHP文件末尾关闭PHP标签(不必要)。

However – this isn’t the only place where our code lies. Themosis is fragmented across two locations – everything related to routing and presentation goes into the theme, while everything to do with our application logic is placed in the plugin’s folder.

看一下MVC结构，我可以说它包装得很好。 当然，如果它不是碎片化的(跨两个父文件夹)会很好，但是结构在那里。 路由文件夹位于Laravel中的文件夹中，并且接受类似的路由语法–幕后，它只是一个增强的条件标记 。 控制器在那里，并且以真正的MVC方式与它们的视图整齐地分开，而从控制器使用模型，并将其返回值传递给视图。 从 ：

As simple as it gets. Views are traversed with the dot-notation, folder-wise, and their suffix is ignored but required, so leads to – all quite straightforward.

就这么简单。 视图是按点表示法(按文件夹)遍历的，它们的后缀被忽略但是必需的，因此， 会导致 –一切都非常简单。

用参数路由 (Routing with params)

Looking at some of the routes, the simplicity is immediately apparent. For example, let’s take the Search page. This is a page so simple, it literally needs only to call WP’s underlying search mechanism, so no controller is necessary:

查看一些路线，简单性立即显现出来。 例如，让我们进入“搜索”页面。 这是一个非常简单的页面，它实际上只需要调用WP的基础搜索机制，因此不需要控制器：

The root view is rendered, the search GET parameter is passed in (though it should probably be filtered), which then references the results returned by the search function automatically, and loops them with the Loop class mentioned above – the Loop is a simplified, more approachable Loop.

呈现了根视图 ，传入了搜索GET参数(尽管可能应该对其进行了过滤)，然后该参数自动引用了搜索功能返回的结果，并使用上述Loop类将它们循环-简化了Loop ，更平易近人的Loop 。

I like this due to not only simplicity, but also the fact that it abstracted WP’s search function which is, by default, abysmally awful. This makes replacing it much easier.

我之所以喜欢它，不仅是因为简单，而且因为它抽象了WP的搜索功能，默认情况下，它的功能非常糟糕。 这使得更换它容易得多。

You can see more info on routing here, or just look at the examples.

您可以在此处查看有关路由的更多信息，或仅查看示例。

使用Controller + View定义自定义页面 (Defining a Custom Page with Controller + View)

Let’s see if creating a custom page with a view-controller combination is as easy as advertised.

让我们看看使用视图控制器组合创建自定义页面是否像宣传的那样容易。

First, we’ll put a new route into :

首先，我们将新路径放入 ：

Then, we create a new view under called :

然后，我们在名为 下创建一个新视图：

Finally, we add a new controller into the folder:

最后，我们在文件夹中添加一个新控制器：

In essence, this would render “hello world” for the route in any framework, but since Themosis relies on WP’s data in the background (it is an MVC API used for extending WP, after all), we need to do one more thing. We need to actually add the page to the system, because of the way routing works.

但是我们保存了“有人在吗？” 在内容中，不是Hello World –视图中是Hello World –有什么用？ 好吧，要在视图中实际包含页面的内容，我们需要访问控制器中的全局变量并将其传递到视图中，以便我们可以使用其属性。 不幸的是，Themosis并没有什么办法减轻可湿性粉剂闻名的污染。

If we change our controller to actually fetch the page in question:

如果我们更改控制器以实际获取有问题的页面：

and then add the necessary logic to the view:

然后向视图添加必要的逻辑：

…we can get our page rendered as expected:

令人费解？ 也许有一点，但是我想一个人已经习惯了。 在这里重要的是，我们获得了强大的包装器，用于渲染所有通常可访问的WP内容，这为我们提供了新的结构和清晰度，使WP具有以前从未有过的刚性。

Think of developing with Themosis as Laravel powered WordPress plugin development – if the core of WP is that hopeless, there’s no need for the plugins to be. Themosis brings much needed structure and encapsulation to the otherwise chaotic and unmaintainable plugin architecture you may have gotten used to.

考虑使用Themosis作​​为Laravel支持的WordPress插件开发进行开发-如果WP的核心是没有希望的话，则不需要插件。 Themosis为您可能已经习惯的否则混乱且无法维护的插件体系结构带来了急需的结构和封装。

Themosis is still in its infancy, being 0.8, but version 1.0 is around the corner and we wish the developer much luck and success in this endeavor – good design practices need to be spread around the PHP world like a vaccine, and if one way of doing that is through a good-practice powered plugin framework on a bad-practice core, so be it.

Themosis仍处于起步阶段，为0.8，但1.0版即将来临，我们希望开发人员在此过程中万事如意，并取得成功–良好的设计规范需要像疫苗一样在PHP世界中传播，并且如果有一种方法可以做到这一点是通过在不良实践核心上使用良好实践提供动力的插件框架。