WordPress

This product based on PHP 4.1 and requires a MySQL 4.1 database. It's very flexible, has a load of facilities. You can have full control over your publication (well, within wide limits), there is a load of themes available, and many, many plug-ins, including spam-prevention.

Installation is extremely simple, and OpenVMS offers a very flexible way of installing multiple blogs without copying a lot of files (which seems to be the only way to get multiple blogs on other platforms).

Do yourself a favour and install each (major) version in it's own directory, it allows you to test it separately from the blogs that run on other (older) versions. Also create some directory that will NEVER be mapped to the web server, and define a system logical to this directory. Each blog should have it's own directory, containing just the configuration file, and a a directory tree [wp-content] - contents specific for that blog (uploaded files, for instance, and themes and plug-ins). It is an OpenVMS advantage that is not required to do a full installation for each blog, like on other environments

!Wordpress comes as a standard ZIP file from http://www.wordpress.org - you'll find a download link to the latest version on the home page.

As an example, this is my basic blog-environment setup.

Download the latest version of Wordpress (latest WORKING version I found to be 2.6.5).
Put this file on the location where you want the code to reside.
UNZIP the package, it will create a directory [WORDPRESS]
Rename WORDPRESS.DIR to WP<version>.DIR (at the time: WP265.DIR)
DEFINE/SYSTEM WP263 <dev>:[WP265.]/Trans=(concealed)
Create a directory <dev>:[<dirpath>] to store "secret data".
DEFINE/SYSTEM HIDDEN <dev>:[<dirpath>]. This location will hold the data to be kept secret.
SET DEF <dev>:[WP263]
COPY wp-config-sample.php wp-config.php
EDIT wp-Config.php and open a new file HIDDEN:WP263.DB

CUT the lines from wp-config.php you'll need to adjust:

      define('DB_NAME', '<database name>');
      define('DB_USER', '<database user>');
      define('DB_PASSWORD', '<password>');
      define('DB_HOST', '<host>');
      define('DB_CHARSET', 'utf8');
      define('DB_COLLATE', '');
      $table_prefix  = 'prefix';
      define('SECRET_KEY', '<some string>');

and PASTE these lines in a new file HIDDEN:WP263.DB

Change the lines to appropriate values. TIP: keep DB_NAME and PREFIX the same...
Save HIDDEN:WP265.DB and close the buffer.

Add a line:

    require_once('/hidden/wp265db.php');

where you removed the lines.

Save and close the buffer.

Now make this location: WP265, known to your web server. Be sure that .PHP is triggering the PHP engine of the browser. In my WASD server, this is the mapping used:

  redirect /wp265/ /wp265/index.php?
  redirect /wp265/**/ /wp265/*/index.php?
  exec /wp265/**.php (cgi_exe:phpwasd.exe)/wp265/*.php \
       ods=5 script=syntax=unix script=query=none map=once
  pass /wp265/* /wp265/* ods=5 search=none

Now access address "<your server>/WP265/wp-admin/install.php"
Follow the instructions and in 5 steps, you can start testing and experimenting.

Now you want to do it for real. It's very simple. This is how SYSMGR is done:

Create a directory for your blog (<dev>:[<dirpath>] (<dev>:[BLOG.SYSBLOG])
DEFINE/SYSTEM SYSBLOG <dev>:[BLOG.SYSBLOG.]/trans=(conc), WP265:[000000.] /trans=conc
COPY WP265:[000000]wp-config.php SYSBLOG:[000000]
COPY HIDDEN:wp265db.php HIDDEN:sysblogdb.php

Just to be sure:

      PURGE WP265:[000000]
      RENAME WP265:[000000]wp-config.php;0 wp-config.php;1

SET DEF SYSBLOG:[000000]
CREA/DIR [wp-content]/PROT=W:RWE. This is needed to allow uploads...(if you don't accept uploads, keep this to W:RE)
EDIT wp-config.php

Change include line to refer the right file

          require_once('/hidden/'''sysblogsb'''.php');

Save and close wp-config.php
OPEN HIDDEN:sysblogdb.php
Edit every line as appropriate. DB_NAME and PREFIX must be different, the rest is typically equal to WP263.
Save and close HIDDEN.sysblogdb.php

Now make this location: sysblog, known to your web server. Be sure that .PHP is triggering the PHP engine of the browser. In my WASD server, this is the mapping used:

  redirect /SYSBLOG/ /SYSBLOG/index.php?
  redirect /SYSBLOG/**/ /SYSBLOG/*/index.php?
  exec /SYSBLOG/**.php (cgi_exe:phpwasd.exe)/SYSBLOG/*.php \
       ods=5 script=syntax=unix script=query=none map=once
  pass /SYSBLOG/* /SYSBLOG/* ods=5 search=none

Now entre the address "<your server>/SYSBLOG/wp-admin/install.php"
Follow the instructions and in 5 steps, you can start blogging!

different database

To test how Wordpress would work with the OpenVMS port of MySQL version 5.1, I created a database to be read on port 3307 - see the Mysql update discussion. In the blog configuration, all you need is add the port after the hostname:

define('DB_NAME', '<database name>');

becomes

define('DB_NAME', '<database name>:<port>');

(whatever port you defined for the database)

Next fire up the blog and start testing.

Note on Wordpress 2.6 (and following)

WordPress version 2.6 contains a number of files that have a dot in the filename, and UNZIP will replace this by "_" - causing a problem in loading the file. Solution is to rename these files to contain the dot in stead of the underscore, OR edit the loading script to use "_" instead. This has been mentioned to the WordPress team, I suggested to use "_" or,"-" - they had so before. Hopefully they do read the feedback forum. But I doubt it will change (Following versions in the 2.6 frame had the same names, so: No. They don't)

Another issue that may bite: There has been a change in the encryption scheme used in login. It may render your blog inaccessible, but you can get around it using the "Forgot my password" possibility. Changing a password may work, or not. I got messages of an non-CGI-compliant result: somewhere, a CR/LF couple is simply ignored and the reply to the server is:

Status: 302..X-Powered-B

Must be the PHP code since it's the only place where it runs off the rails.

Update It might even be a glistch in the PHP engine...

Note on Wordpress 2.6.3 (and following)

This has been found by Francesco Gennai, and I noticed it as well: The HP-supplied PHP_SHR contains a module for processing regular expressions that is not linked to support UTF-8 character sets. This sometimes is a problem, and I found in one place it could be bypassed by specifying another value in the database: In table OPTIONS, there is one record where field "Option_name" equals "BLOG_CHARSET", and usually field "Option_name" is set to "UTF-8", by default. Like MySQL itself, that uses this set itself. Using this value, the code will execute code and raise this error. Replace ÜTF-8" to another value, for instance "CP850" - the Windows codeset for Western Europe - and the problem is gone in some places. But on other, it's not that easy, and you'll have to change the PHP code to bypass these routines. If possible, at all...

More problematic: by this error, embedding an uploaded image in a blog entry fails for some reason, but that may be a browser issue: The edit page does not show up, because of an Javascript error. As a work-around: Show this page's source, it's the Javascript that would be rendered into the edit page. It contains the link , so cut it from there and paste it in the HTML form on the page's text box.

Another error - caused by another PHP engine (linked against MySQL 3 or 4?) and a MySQL 5.1 database: Login is troublesome. IE won't pass information properly, and the admin pages won't show up. Firefox seems to do it right, but even there there could be a problem with pages not showing.. To get around the problem, SAVE the login information, close the browser and restart, and access the blog. Now you will have "Site manager" login and "edit" links near your posts.

Note on changes

If you make changes that could impact the execution of code (like changing filenames) don't forget to stop any process that might be executing the PHP code. That implies subprocesses of the web server. For WASD, check, in the administration panel, under DCL, which processes are running PHPWASD. Force them to exit; clear cache of both server and browser, and retry. Otherwise you may use loaded code that does not incorporate the changes...

Note on SSL

If you create a new Wordpress blog on a secured site, there is a glitch in the creation of two records in the OPTIONS table: Both "Site URL" and "HOME" keys mention "http" where "https" should have been used. It causes CSS files to be ignored, and other accessed fail as well: You won't see much content, login and admin access will both fail with a "page not found" error. The solution is easy: access the database directly ($ mysql, or over the web using phpMyAdmin) and change these two records to mention https in stead of http. This has been mentioned in the feedback forum on Wordpress. But I don't think it will be changed.

Note on version 2.8 and following

I have found that from version 2.8 onward, there is a problem within either the PHP code of WP, the processing of the REDIRECT statement by the PHP engine, or with mapping in WASD. Anyway: the basic pages do not show up, because there is a redirectiom to the same page time after time. That is: IE times out, Firefox signals the problem. The WASD WATCH log also shows the redirection problem, and the same page will be pushed to the engine, again and again, without HTML being returned for the webserver to pass to the browser. I've found this with 2.8 and 2.8.1, and quite likely, it will happen in 2.9 and 2.9.1 (being the latest version today)