edin.no-ip.com

Here is a Drupal related news from a Hong Kong magazine PC Market Vol.856 on 2009-12-22, BizIT, Let's Open section (p.156):
白宮群英CMS篇: Drupal: PC Market Vol.856, 2009-12-22

作為開源軟件的Drupal，是一個採用PHP程式語言編寫、模組化框架架設的內容管理系統（Content Management System，CMS）。由於其功能及意義超過了一般的CMS，故有人稱它為內容管理框架。Drupal可以在Windows、Unix及Linux等作業系統上進行，背後需要MySQL或PostgreSQL等的數據庫系統作出支援，亦可以配合Apache及IIS的網頁伺服器運行。

剛剛推出版本6.0的Drupal，擁有多項方便內容管理的新功能。一）支援使用OpenID，讓用戶可以在互聯網上享用單一的識別身分，在使用一眾支援OpenID的網站下，用戶毋需再在不同的網頁內，輸入不同的登入姓名及密碼，提升使用的體驗；二）自動檢查功能，系統將會定時找尋模組軟件及其他安全更新，步驟自動化，令系統管理員省卻管理的時間。除此之外，Drupal 6亦作出大量的系統優化程序，包括國際化語言支援，除了全球最多人使用的英文及中文外，其他從右向左書的語言亦已步入支援之列，足令Drupal的世界用戶群數繼續增加。

Drupal的穩定性及功能強勁亦獲美國總統奧巴馬垂青，在今年10月起，白宮建立的whitehouse.gov網站討論區，就改用了Drupal作為系統架構的基礎。

As a people living in Hong Kong, I feel so happy about this news. Some website designer in Hong Kong still think that "Using CMS or some other website framework will simple remove their development flexibility; the learning curve of CMS is too high which may not really improve their project performance; etc." This is a good signal that more people are now searching for better website development solution, rather that just simple static page design :D

This mini-HOWTO will guide you though the integration procedure for both Drupal and Gallery2, with assistance of FCKeditor and G2Image. If you hope to insert your photo album images into Drupal without a heavily embed style, this should be your cup of tea.

Why not integrate with Drupal's gallery.module?

The most simple answer should be: keep everything simple. I hope to keep my Drupal and Gallery2 installation isolated for a simpler management, as different system coming with different specific requirement. What I only hope to do is to reuse the existing resource coming from Gallery2, so user don't need to upload a single image twice.

Why not use Drupal's image.module + img_assist.module?

They are in different design so I use both solution. I use image.module + img_assist.module for tiny amount Drupal-only images, for fast layout design and so on, e.g. insert some image when writing a blog post as like as this mini-HOWTO. You won't hope to: 1. create a new album in Gallery2, 2. upload images and manage their title, 3. go back to Drupal and choice your image though FCKeditor, how fancy!

Demo Drupal and Gallery2 setup

In this HOWTO I will install Drupal and Gallery2 as path below:

Why a lot of symlink? Because whenever upgrade is required, I just need to download the new version and relocate the symlink target. No path or URL will be changed.

So if my server with URL http://example.com/ and Apache DocumentRoot on /var/www, Drupal and Gallery2 will be accessible though:

Moreover, Drupal's FCKeditor is already installed in:

Where G2Image already installed in:

Download G2Image here, and also read its general installation guideline.

G2Image Drupal-specific configuration

Edit the /var/www/drupal-6.x/sites/all/modules/fckeditor/fckeditor.config.js, and add the following line:

I add the G2Image button to both DrupalFull and DrupalFiltered, so it should look like:

Now edit the /var/www/drupal-6.x/sites/all/modules/fckeditor/plugins/g2image/config.php as below:

Ok that's all :D

Test the setup

Create a new node, activate the FCKeditor, and you should have something similar as below:
drupal_g2image-001.png

When click on the G2Image button, you should able to browse your album, select and insert your images:
drupal_g2image-002.png

Once insert your editor should look like:
drupal_g2image-003.png

Ok so now save the node and review it. Enjoy :D

I have been using Drupal's Adsense Injector for more than years and love it so much: it is simple, elegant and just enough. But since my personal blog upgrade to Drupal 6.x, I get some trouble with it as there is no official release for Drupal 6.x. Well... I need to hack 5.x version for 6.x manually...

An upgrade patch is submitted 8 months ago which now obsoleted. Finkpad ask help from my blog directly, so Michael Curry and I start some join development for getting the work done.

If you are looking for this handy module as me, please feel free to download the latest 6.x-2.x development snapshot for testing and report bug if possible. With you kindly help stable release should be out soon :D

This is a quick checklist for develop Drupal 7.x Oracle driver. They need to be solved before Oracle slip into Drupal core.

Reserved word conflict (integrate with siren)

Drupal core use some reserved word of Oracle, e.g. uid. To solve this we have 2 choice: 1. escape all table/column/constrain name with escape characters (http://drupal.org/node/371#comment-636053), or 2. clone Moodle implementation and prevent the use of reserved words for all supported database (http://docs.moodle.org/en/XMLDB_reserved_words).

Here we choose to use solution 2. This come with some extra benefit that, if we need to connect Drupal's database from other projects, e.g. Moodle, they will able to fetch Drupal's column as there is no reserved word conflict. So this can improve both cross database and cross project compatibility.

Related issues:

• resolve ANSI SQL-92/99/2003 reserved words conflict in query statements
  • [Oracle] replace reserved word 'uid' and 'access'

VARCHAR2 is no large enough, use BLOB instead (integrate with siren)

This is another critical issue. Oracle only support VARCHAR2 with maximum 4000 characters. It is always not enough for CMS. As a replacement we can use BLOB because it is more universal.

We also need to clone PostgreSQL's BLOB handling for Oracle, with RETURNING.

Related issues:

• [DBTNG + XDB] Replace some TEXT:BIG with BLOB (27/11)
  • Remap field as BLOB: {boxes}.body (27/11)
    • [DBTNG] revamp modules/block/* with DBTNG syntax (27/11)
  • Remap field as BLOB: {menu_router}.access_arguments and {menu_router}.page_arguments (27/11)
    • [DBTNG] revamp menu.inc with DBTNG syntax (27/11)
  • [DBTNG + BLOB + hash]: Revamp locales_source.source with BLOB and MD5 hashing (27/11)
  • [DBTNG + BLOB]: remap {watchdog}.variables (duplicated)
  • [DBTNG + BLOB] remap {comments}.comment (duplicated)
  • [DBTNG + BLOB] remap {aggregator_item}.description (duplicated)
  • [DBTNG + BLOB] remap {batch}.batch (duplicated)
  • [DBTNG + BLOB]: remap {node_revisions}.body and {node_revisions}.teaser (duplicated)

Empty string is not allow in Oracle, and will translate as NULL (integrate with siren)

This is a critical bug of Oracle, all empty string will translate as NULL automatically. It is NO WAY for Oracle to emulate as other RDBMS because it is a 2-state machine (valid or NULL) but not 3-state (valid, empty or NULL). Logic Diagram:

In order to overcome this limitation, we can first extend as 4 states: valid, "default", empty or NULL. Then restrict the use case as 3 states only, with replace the use of empty string as "default" value. Therefore both Oracle and other RDBMS can have identical support of SQL, and don't need to duel with different between = '' and IS NULL. Logic diagram:

Procedure: 1. update all schema as nullable string if required (only allow null with valid default value but not empty string), 2. restrict all string I/O with no empty string (force translate as NULL), 3. debug and update programming logic for using empty string with "default" value if possible. Therefore:

• Valid value: Keep untouch.
• NULL: Act as default replacement of empty string if no programming logic break.
• 'default': Use as exceptional replacement of empty string, work together with programming logic revamp.

P.S. This change will also benefit with the critical PostgrerSQL Blob bug with empty string (http://bugs.php.net/bug.php?id=41135), because we will no longer use empty string.

Related issues:

• [DBTNG + XDB] NOT NULL fields using a DEFAULT '' clause (27/11)
  • Use 'default' instead of '' as default actions parameters (duplicated)
  • Use 'default' instead of '' as default user name and password (duplicated)
  • Use 'default' instead of '' as undefined default language (duplicated)
• [DBTNG + pgsql] db_insert/db_update buggy with empty string input and BLOB field

Auto upper case table and column name (integrate with siren)

This can be handle with PDO::ATTR_CASE (http://www.php.net/manual/en/pdo.setattribute.php). Becareful! Field names should be reserved word safe.

Related issues:

• Force connection with PDO::CASE_LOWER

Max 30 characters for constraint name restriction (integrate with siren)

Oracle only allow 30 characters for constraint name. Moodle give a good example for solving this problem.

Related issues:

• [DBTNG + XDB] revamp key and index naming

Some SQL functions need abstraction (integrate with siren)

Different database coming with different SQL syntax for same function, e.g. MySQL use SUBSTR, where PostgreSQL use SUBSTRING. Some simple abstraction is required. ADOdb give a good example for solving this problem.

Related issues:

• [DBTNG + pgsql] Handle database-specific SQL functions/operators by simple abstraction

According to news (2008-10-09) from group php.internals, PHP 5.2.7 should have a final release out in the next 2-3 weeks:

The first release candidate of 5.2.7 was just released for testing and can be downloaded here:

http://downloads.php.net/ilia/php-5.2.7RC1.tar.bz2 (md5sum: be7544212fe4a3ede775a3793ecd3967)

The Windows binaries should become available shortly as well, for now you can grab the win32 snapshots from snaps.php.net. This release has been long in coming, so the NEWS file looks quite impressive with an extensive number of bug fixes. I do not believe any of the fixes are bound to introduce any regression and the hope is to have a final release out in the next 2-3 weeks. To make this possible, please test this RC against your code base and report any problems that you encounter.

Ilia Alshanetsky
PHP 5.2 Release Master

Since the PDO PostgreSQL BLOB issues is now get fixed in CVS of both PHP 5.2.x and 5.3.x (read more), it should come with official release soon. Thanks god that as Drupal 7.x is now binding with PDO only, the PostgreSQL support status is now hopefully safe.

P.S. As I am now working with Drupal 7.x + Oracle, pdo_oci may also come with some hidden issue, too. I should speed that up in order to get it done :D

Long story short, PHP 5.2.6 pdo_pgsql is buggy with BLOB INSERT/UPDATE. Both NULL and empty string are saved as NULL when pass into PostgreSQL, and so programming logic may break.

It is now fixed in latest PHP CVS, both 5.2.x and 5.3.x. All packages newer than snapshot php5.2-200810130030.tar.gz. is safe from this issue. Please refer to PHP bug report for more information.

As Drupal 7.x is now revamped with DBTNG and using PDO as the only default support database driver, this is a critical issue for its PostgreSQL support status. Patch is submitted and pending for review. Please refer to Drupal bug report for more information.

How to check if my PHP is safe from this bug?

You can follow the bug reproduction guideline and its latest version of code snippet. Check your result and see if all logical comparison of original data and fetched value are return as TRUE.

What can I do with this bug?

If you are a Drupal 7.x core developer which focusing on PostgreSQL support status, please download PHP snapshot newer than php5.2-200810130030.tar.gz manually, and give a hand for the commit of related Drupal bug report. If you need some help for the manual PHP installation, please refer to my HOWTO for more information.

If you are normal Drupal user which will use PostgreSQL in coming future, please be patient and wait for the release of PHP 5.2.7 (it is now 5.2.7RC2). You may also keep your eyes on the update status of the Drupal bug report, and help the promote of using PHP 5.2.7 as minimal support version for Drupal 7.x public release.

After a week from the successful Drupal section in BarCamp Hong Kong 2008, today we have our 1st pre-meeting for the startup of Hong Kong Drupal User Group (HKDUG), together with friends who are interested in using Drupal, and also plan for the detail of our coming off-line gathering on Sept. 25th. It is a nice gathering, especially with coffee break :D

Today is a public holiday in Hong Kong, after the Mid_autumn Festival. This 5 members off-line gathering is hosted in Pacific Coffee of Festival Walk at Kowloon Tong. The target of today is very simple: we are going to host a another gathering on Sept. 25th, so just sit down and brainstorming the presentation schedule with coffee; on the other hand, think about if we are going to startup HKDUG with the support of our own portal page (e.g. http://drupal.org.hk/), discuss and handle those legal restriction based on Hong Kong Government.

I have a good day in BarCamp Hong Kong 2008: meet a lot of new friends (Drupal or not), join the section of "The Hong Kong Startup Association" and "Open Source + Microsoft" (it is a good talk show, even I don't really love M$ so much...), prepare a section for Drupal about "Drupal Theme Development", and also join the "Startup Lightning Talks" with topic of "eLearning in Hong Kong". I can only say that: it is great as I can join this event :D

After Drupal section, Hong Kong Drupalers (around 25 people!) hope to have some indeed interconnection and cooperation, and we both express our wish for having more meeting in feature! So I give a startup for Hong Kong Drupal User Group in Facebook.com, planning for another offline meeting within the next 2 weeks, setup the user group homepage with drupal.org.hk, and so on! This was something that I dreamed with Dava half years ago, and now I guess it is a suitable timing for kick start everything. If you are Drupaler from Hong Kong, don't miss this chance to join us in both Groups.Drupal (Hong Kong) and Facebook.com!

P.S. It is very pity that I didn't prepare my name card and camera! Since I just knew this event one day before and so... Anyway, I will be smart for next time! Here are some photographs from other:
2837038452_d164a8878f_b.jpg2836266617_37f4a1b5c0_b.jpg2837121888_f5aa5fafb9_b.jpg2837195274_3b919d0e80_b.jpg2837199180_0459c67c47_b.jpgImage00026_001.jpgImage00027_001.jpgImage00028_001.jpg2837241798_ce92c8fb41_b.jpg2832561325_9f88aea1be_b.jpg2837233146_8c6708da77_b.jpg2836464497_aa0884a967_b.jpg

A good invitation from Groups.Drupal (Hong Kong), about BarCamp Hong Kong 2008. I will try to share my research founding with Drupal 7.x + Enterprise DB backend, e.g. Oracle, DB2 and MSSQL; some tricky skill for integrate 3rd layout design with Drupal; also hope to gather with Hong Kong Drupaler and discover for our possibility.

Are you living in Hong Kong? Are you using or interesting with Drupal? Do you hope to meet more friends and share your idea? Is time to show up, and I will be there waiting for you. Let's meet on tomorrow :D

Reserved word conflict is an always pain for multiple DB backend supported system: Drupal also face this for many years (e.g. http://drupal.org/node/371, since June 30, 2002). This is the most complicated bottleneck for daily maintenance and introduce any new DB backend to Drupal: whenever existing DB vendor change their standard, we need to follow it; whenever a new DB backend introduce, another set of reserved words are coming in, too.

There is many possible solution, e.g. prevent use of ANY reserved words based on requirement of ALL supported database engines (as like as Moodle's implementation); BTW, as this solution will left issue as ALWAYS OPEN, I am not going to discuss within this review.

Another possibility is the use of escape characters, e.g. `` for MySQL, "" for PostgreSQL/Oracle/DB2 and [] for MSSQL. This approach is widely used for many successful projects, e.g. phpmyadmin, phppgadmin, Oracle/DB2/MSSQL EM. The primary consideration is: How to implement this syntax for Drupal, which is simple and elegant for both end user and DB abstraction designer?

For sure that we will need some update for existing Drupal queries syntax, where the ultimate goal is query will finally present as following example before process by PHP database connection (e.g. SELECT batch FROM {batch} WHERE bid = :bid AND token = :token from line 15 of includes/batch.inc, CVS HEAD, rewrite with TNG DB standard). In case of MySQL, after translation it should looks like:

I will discuss different syntax change approach, based on: a) user experience, b) similar to ANSI coding style, c) backward compatibility, d) backend complexity, e) overall performance and f) workload for syntax conversion. A simple marking will be given for each item (e.g. good/functioning: 2; fine/not bad: 1; poor/not functioning: 0) so we can have some simple idea between different proposals.

Here is a quick rundown of my review:

• Solution 1: Only use one set of bracket ({} or [] only) => 6 pt.
• Solution 2: Mix up both {} and [] syntax => 8 pt.
• Solution 3: Single set of bracket, but making column escape special => 3 pt.
• Solution 4: Single set of bracket, but making table name special => 10 pt.
• Solution 5: Keep existing table name syntax, where add [] as escape character placeholder only => 11 pt.