You are here

drupal8

内容包括drupal8教程,drupal8汉化,drupal8主题,drupal8模板,drupal8中文手册,drupal8 views,drupa8中文,drupal8安装,drupal8开发,drupal8视频,等

Ubercart VS Commerce

Ubercart与Commerce的竞争,在持续了4年之久之后,两者的前途,逐渐明朗了起来。Ubercart仍将继续的存活,并稳步上升,随着Drupal8的问世,两者会走上两条完全不同的道路。

在Drupal8下,Ubercart持续开发,很多功能都紧紧的跟上,Ubercart是以一个笨鸟先飞的角色出现的,在Ubercart的Drupal8版本持续开了1年半之久的现在,Commmerce的Drupal8版本还没有动工,而现在Ubercart的Drupal8版本吸引了更多的开发者。这意味着,Ubercart在Drupal8下,继续存在,健康发展。

Commerce发展的也不错,在Drupal7上,势头比Ubercart好,但是Commerce并没有占据压倒性的优势。Drupal本身市场狭小,基于之上的电子商务不足10%,而Commerce只占据这10%里面的50%不到,所有的这一切加在一起,都制约着Commerce guys的发展。

论坛:

Drupal版本:

Drupal8 Beta版即将发布

从目前的状态来看Drupal8的第一个beta版将会在2014-6月底发布,当然,只有50%的可能性,还有45%的可能性是在7月发布,5%的可能性推迟到8月了。

现在还有14个Beta block问题需要修正,其中两个是关于document的,4个已经处于绿色的状态,等待检查,没有问题,就会commit进去,还有4个是被postphone,其余的几个,也都进入了尾声阶段。

到这个月底,Beta block问题数量将会被控制在6个以内,我想会是第一次达到0个,很有可能,这个月发布beta版。

另外,这个月举办了Drupal大会,很多全球的开发者,聚到一块,在会议的结束,有代码冲刺,这个将会加快进度。

Drupal8的进度一拖再拖,我的想法是,很多Drupal的大公司,并不想快一点发布Drupal8,因为他们想从Drupal7中赚取跟多的钱,导致了应该在2013年9月发布RC版的Drupal8,到现在还没有出现beta版。

Drupal8的一拖再拖,已经损害了这些大公司的利益,他们现在应该意识到Drupal8的及早问世,为他们带来更多的利益。

综上,分析,Drupal8将会在这个月发布beta版,很有可能。Beta版的发布,意味着Drupal8的降临,已经进入到了实质阶段了。

论坛:

Drupal版本:

Ubercart的支付方法,率先采用插件机制

Ubercart的Drupal8版本,已经开发了1年多的时间了,这无疑是一个鼓舞人心的消息。而与之形成对比的是Commerce模块,毫无动静。
在Ubercart4.x,支付方法,结算窗格,运费计算方法,都将采用插件的形式,我们现在先读为快:

/**
* @file
* Contains \Drupal\uc_payment\Plugin\Ubercart\PaymentMethod\FreeOrder.
*/

namespace Drupal\uc_payment\Plugin\Ubercart\PaymentMethod;

use Drupal\uc_order\UcOrderInterface;
use Drupal\uc_payment\PaymentMethodPluginBase;

论坛:

Drupal版本:

Quicksketch自动从Drupal8除名

今天在Drupal核心的Issue当中,看到这样一篇,https://drupal.org/node/2066783, 从MAINTAINERS.txt中删除quicksketch,这篇文章的作者就是quicksketch。

    经过一番反复的思想斗争,我认识到,Drupal8不再是我所爱的一个系统了,我想从MAINTAINERS.txt中除名,从此不再担负起Drupal核心将来版本的维护工作。Drupal8不再是一个我能够理解并使用的系统了,更不用提自己去贡献时间来维护Drupal8的核心代码了。如果Drupal8正式版发布后,或许自己有可能改变这个想法,但是从现在来看,希望渺茫。无论如何,Drupal应该由那些了解其底层架构的人来维护。不过现在,我原来所写的代码,都已经不复存在了。

Quicksketch是Drupal核心模块维护者Image和File模块的作者,webform的作者,Lullabot的Drupal架构师级。

从这件事情上,可以看出:

论坛:

Drupal版本:

区块:实体 VS 插件?(Drupal8系列)

区块系统,一直是Drupal里面的最重要的组成部分,随着技术的发展,尤其是有了CCK模块以后,Drupal用户,很多人希望能够使用CCK扩展区块。其中的一种解决方案,就是把区块处理成为一种节点,这是Drupal6下的解决办法。

到了Drupal7,区块系统并没有升级到实体,但是有第3方模块,BEAN,可以将区块处理成为实体。将区块处理成为实体,是一种趋势。

我们这里所说的,是自定义区块,就是通过Drupal后台创建的区块,我们知道,第3方模块,通过代码也是可以创建区块的,这些通过代码创建的区块,在Drupal7下,是通过钩子函数出现的,在Drupal8下,需要将其改造为插件的形式。

因此,在Drupal8下,通过代码,也就是说通过插件可以定义区块;而对于Drupal后台创建的区块,则是实体的形式,这是通过区块模块的子模块custom_block实现的。

因此,可以说区块既是实体,又是插件。当然这样说还是有点问题的。改造为实体以后,很多相关的第3方模块,将会消失,比如说我开发的block_morelink模块,在Drupal8下,就没有多少实际用处了,除了教学以外。

是的,每一个Drupal主板本的问世,都意味着一大批的第3方模块的消失、淘汰。同时也意味着,一大批新的模块的兴起。

论坛:

Drupal版本:

逐渐消失的钩子机制(Drupal8系列)

很早以前,我们学习Drupal的时候,都会被告知,钩子(Hook)机制,是Drupal中最核心的概念。在Drupal7里面,钩子大概分类3类:module_invoke_all调用的钩子,module_invoke调用的钩子,以及主题函数也被称之为主题钩子。

我曾经给人讲过,Drupal7,是最后一个面向过程的版本,而Drupal8则是第一个面向对象的版本。从面向过程,到面向对象,底层的代码经过了一系列的重构,这也使得Drupal能够充分的利用已有的语言层级的先进技术。

实际上,在Drupal7中,核心里面,很多地方都已经使用了面向对象的技术,但是此时的面向对象,只是起到辅助性质的作用,面向过程则是最基础的;但是这并不影响,第三方模块向面向对象的转变,很多的第三方模块,底层都是基于面向对象的。比如说Feeds、Views模块,而我在Drupal7下面所写的Field validation模块,第一版是面向过程的,第2版主要就是基于面向对象的。

论坛:

Drupal版本:

drupal_write_record

Drupal提供了很多API函数,学习这些API函数,需要比较多的时间,但是,一旦学会了,使用Drupal自己的API函数,就会给我们带来很多的方便。drupal_write_record就是这样的一个Drupal API函数。

drupal_write_record($table, &$record, $primary_keys = array())

这个函数包含三个参数:

$table、数据库表的名字,必须定义在schema中。

$record,一个要被插入的对象或数组,这里使用的是引用传递。

$primary_keys,如果没有设置主键,表示新建;如果设置了主键,则表示更新。

 

drupal_write_record的优势,就是将Drupal数据库的插入、更新操作合并成一个。统一了起来。我们来看一下drupal_write_record的源代码:

function drupal_write_record($table, &$record, $primary_keys = array()) {

  // Standardize $primary_keys to an array.

drupal慢?不,Drupal很快

很多人刚接触Drupal的时候,总是感觉Drupal很慢,即便是在本地,装了几个Drupal模块以后,感觉就跑不动了。这个本身和本地环境的配置也有关系,建议修改php.ini文件,将PHP的内存,执行时间都调的大一点。这样就不会感觉慢了。

模块不要装太多,尤其是安装量比较小的Drupal模块,更应该注意。模块太多,对于性能的拖累也是非常明显的。

网站上线后,建议开启所有的缓存。性能优化的关键就在于缓存。有各种层次的缓存技术,具体可以参看Think in Drupal 第三集里面,有关性能优化的介绍。

 

Drupal6比Drupal5慢, Drupal7比Drupal6慢,Drupal8比Drupal7慢。其中,Drupal7的性能问题最为突出,性能比Drupal6慢很多。Entity API模块用的时候,要小心,很吃内存,也存在潜在的性能问题。顺便说一句,Commerce比Ubercart慢,具体慢多少,没有实际测试过,这是应该的,Commerce大量的使用Entity API,对性能影响很大,性能问题一直也是让commerce头疼的问题。

页面

Subscribe to RSS - drupal8