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.
不久前，我们听说了一个即将到来的名为Themosis的新项目，该项目是“ WordPress开发人员的框架”。 在本篇文章中，我们将尝试看看Themosis是什么，如何开始使用它，并且我们将看一个用它构建的示例项目-Themosis本身提供的示例 。
To anyone familiar with the word “framework”, especially in the context of PHP, this might sound confusing. Isn’t WP already packed full with stuff we don’t need? Aren’t frameworks usually built on a minimalistic set of principles and decoupled components, and complex WordPress-like apps built on top of them, instead of the other way around? Well, yes.
对于熟悉“框架”一词的任何人，尤其是在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支持功能。 例如，模板循环：
@loop(array('post_type' => 'post', 'posts_per_page' => -1)) <h1>{{ Loop::title() }}</h1> <div> {{ Loop::content() }} </div> @endloopuses WP API to get to the data it requires, and the Loop class is designed only to be used with loops for underlying WP content.
使用WP API来获取所需的数据，并且Loop类仅设计用于基础WP内容的循环。
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提供了其网站上的一个应用程序示例- 书店应用程序 。
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盒。 然后只需注册一个新站点：
- map: bookstore.local to: /home/vagrant/Code/themosis_exampleOf course, don’t forget to add the bookstore.local alias to your host’s hosts file as described in the Homestead Improved Quick Tip.
当然，不要忘记按照Homestead改进的快速提示中的说明，将bookstore.local别名添加到主机的hosts文件中。
Clone the repository with git clone https://github.com/themosis/bookstore themosis_example, and visit http://bookstore.local:8000 in your host’s browser to get to the installation procedure.
使用git clone https://github.com/themosis/bookstore themosis_example克隆存储库，并在主机的浏览器中访问http://bookstore.local:8000来获取安装过程。
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.
按照说明安装后，即可试用该应用程序。
At this point, this is nothing impressive – any WP site can be configured to look and work like this. However, I noticed two key points:
在这一点上，这并不令人印象深刻–可以将任何WP网站配置为外观和工作方式如下。 但是，我注意到两个关键点：
We got it to run fairly quickly, it was a real no-hassle job. 我们让它运行得相当快，这是一项真正的轻松工作。 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?
那代码呢？ 看起来像什么？
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:
您可以在书店存储库中检出代码： https : //github.com/themosis/bookstore 。 让我们看看我们能看到什么。 就像我上面说的，Themosis实际上是一个插件，因此我们需要在插件中查找书店的代码：
Opening this, we can find three main subfolders. app contains the logic of our Themosis-powered WP layer, src contains the sources of Themosis itself (which, if you look through them, you’ll notice bear a striking similarity to class names and folder structures of other, more popular frameworks), and we all know vendor – the place where everything Composer-fetched goes.
打开它，我们可以找到三个主要子文件夹。 app包含由Themosis驱动的WP层的逻辑， src包含Themosis本身的来源(如果仔细查看它们，将会发现与其他更流行的框架的类名和文件夹结构有着惊人的相似性)，我们都知道vendor -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 <?php defined('DS') or die('No direct script access.'); line used for preventing direct access to PHP scripts, or closing PHP tags at the end of PHP files (unnecessary).
关于代码的实际质量，尽管它的某些方面最肯定是现代的并且符合当今的标准(命名空间，类)，并且所有代码都精美地记录了返回类型，参数和整个九码，但仍有(我说这完全意识到我也在挑剔一些原始文物，例如<?php defined('DS') or die('No direct script access.'); 该行用于防止直接访问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.
但是–这不是我们的代码所在的唯一地方。 Themosis分散在两个位置–与路由和表示相关的所有内容都成为主题，而与我们的应用程序逻辑相关的所有内容均位于插件的文件夹中。
Looking at the MVC structure, I can say it’s well wrapped. Sure, it would be nice if it weren’t this fragmented (across two parent folders), but the structure is there. The routes folder is in the app folder, as in Laravel, and accepts similar syntax for routing – under the hood, it’s just an enhanced conditional tag. The controllers are there, and neatly separated from their views in true MVC fashion, whereas models are used from the controller and their returned values passed to views. From home.controller.php:
看一下MVC结构，我可以说它包装得很好。 当然，如果它不是碎片化的(跨两个父文件夹)会很好，但是结构在那里。 路由文件夹位于Laravel中的app文件夹中，并且接受类似的路由语法–幕后，它只是一个增强的条件标记 。 控制器在那里，并且以真正的MVC方式与它们的视图整齐地分开，而从控制器使用模型，并将其返回值传递给视图。 从home.controller.php ：
return View::make('pages.home')-&gt;with(array( 'promo' =&gt; Books::getPromoBook($this-&gt;page), 'books' =&gt; Books::getPopularBooks($this-&gt;bookId), 'news' =&gt; News::get(), 'newspage' =&gt; get_page_by_path('news') ));As simple as it gets. Views are traversed with the dot-notation, folder-wise, and their scout suffix is ignored but required, so pages.home leads to app/views/pages/home.scout.php – all quite straightforward.
就这么简单。 视图是按点表示法(按文件夹)遍历的，它们的scout后缀被忽略但是必需的，因此， pages.home会导致app/views/pages/home.scout.php –一切都非常简单。
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的基础搜索机制，因此不需要控制器：
// Search page Route::is('search', function(){ return View::make('search', array('search' =&gt; $_GET['s'])); });The root view search 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.
呈现了根视图search ，传入了搜索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.
您可以在此处查看有关路由的更多信息，或仅查看示例。
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 routes.php:
首先，我们将新路径放入routes.php ：
Route::only('page', 'test', 'test@index');Then, we create a new view under pages called test.scout.php:
然后，我们在名为test.scout.php pages下创建一个新视图：
@include('header') Hello World @include('footer')Finally, we add a new controller into the controllers folder:
最后，我们在controllers文件夹中添加一个新控制器：
&lt;?php class Test_Controller{ /** * Responsible of rendering the home page. * * @return object. */ public function index(){ return View::make('pages.test'); } }In essence, this would render “hello world” for the /test 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.
从本质上讲，这将在任何框架中为/test路由呈现“ hello world”，但是由于Themosis依赖于后台的WP数据(毕竟，它是用于扩展WP的MVC API)，我们需要再做一遍事情。 由于路由的工作方式，我们实际上需要将页面添加到系统中。
After reloading, our Hello World message renders.
重新加载后，我们的Hello World消息将呈现。
But we saved “Is anyone there?” in the content, not Hello World – Hello World is in the view – what gives? Well, to actually include the content of the page in the view, we need to access the $post global variable in our controller and pass it into the view, so we can consume its properties. Unfortunately, there is little Themosis can do to alleviate the global pollution WP is famous for.
但是我们保存了“有人在吗？” 在内容中，不是Hello World –视图中是Hello World –有什么用？ 好吧，要在视图中实际包含页面的内容，我们需要访问控制器中的$post全局变量并将其传递到视图中，以便我们可以使用其属性。 不幸的是，Themosis并没有什么办法减轻可湿性粉剂闻名的global污染。
If we change our controller to actually fetch the page in question:
如果我们更改控制器以实际获取有问题的页面：
&lt;?php class Test_Controller{ /** * Responsible of rendering the home page. * * @return object. */ public function index(){ global $post; return View::make('pages.test')-&gt;with(array( 'post' =&gt; $post )); } }and then add the necessary logic to the view:
然后向视图添加必要的逻辑：
@include('header') &lt;h1&gt;Page Content: {{ $post-&gt;post_content;}} &lt;/h1&gt; @include('footer')…we can get our page rendered as expected:
…我们可以按预期方式呈现页面：
Convoluted? Maybe a little, but I assume one gets used to it. What’s important here is that we were given powerful wrappers for rendering all the usually accessible WP content, which provides us with new structure and clarity, giving some rigidity to WP where there was none before.
令人费解？ 也许有一点，但是我想一个人已经习惯了。 在这里重要的是，我们获得了强大的包装器，用于渲染所有通常可访问的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世界中传播，并且如果有一种方法可以做到这一点是通过在不良实践核心上使用良好实践提供动力的插件框架。
翻译自: https://www.sitepoint.com/first-look-themosis-framework-wordpress-developers/
