Embedding Piwigo galleries into a WordPress page

We’ve been looking for a new gallery solution for some of our sites and Piwigo looks to have most of the features we are looking for. The unfortunate part is Piwigo is not designed to be embedded. I want to embed the gallery into a page so I can use my WordPress theme to insert the header and footer. It will mean less upkeep as I adjust my WordPress theme, I won’t have to update my Piwigo theme as well.

Piwigo is not designed to be embedded. To get around the problem, I have attempted two different solutions. First was a shortcode. The second method was a custom page template. Both solutions do essentially the same thing. They make a request of Piwigo, get the response back, change the URLs for links, form actions and images, and send the results to the screen. At the moment, both solutions have the same two problems. The title of the page does not reflect where you are in the gallery and logging in does not work.

The title problem is fixable on the template but not on the shortcode, at least not so search engine crawlers can index the images. The problem with logging in is one I’m still working on. Also of note here is that I am currently using some of the standard themes with Piwigo. To make either of these solutions work well, I should create a custom theme that doesn’t output the HTML head section or any header or footer for the page. That’s on the to-do list.

For the logging in problem, I thought the problem was related to cookies. It might still be, but in both cases I have forwarded on the cookies Piwigo sets. It may also have to do with how Piwigo does a redirect after logging in. I need to look into this further.

With any luck, I’ll get these problems fixed. Once I do, I will release the solution for others to use. If anyone is interested in the solution as it is now, let me know. Logging in through the WordPress page doesn’t work, but you can go direct to the Piwigo install to log in. More details to follow.

WP United and WordPress updates

The latest update to WordPress broke my WP-United installation. There is a function definition conflict. At this point, I haven’t done anything to look into the problem other than the “standard” fix attempt of clearing the PHPBB cache. That didn’t work. I will be doing a backup and attempting to correct the problem soon. Will keep you posted when I find an answer.

WordPress Multisite and Separate Domains

In some previous posts, I have talked about getting WordPress Multisite to work across separate domains instead of using subdomains as it was intended. It works with some manual wrangling, but the sites didn’t appear in the Super Admin section that multisite adds to the back end. I decided to try and fix that problem.

The main issue here comes from the table wp_blogs. In that table there are blog ids and site ids. This points to the intent to allow separate domains and separate subdomains in the same install. The problem is that functionality is intended more for a hosted site solution and the separate sites are protected from one another. To make separate domains works, the blogs need to have different site_ids. This is the crux of the problem as the admin takes the current site_id into account when making the blog list in the super admin. To fix the problem, I removed the reference to site_id from the queries.

in wp-admin/ms-sites.php there are several queries that populate the multisite admin and some code to protect sites from one another. Since my files are edited, I cannot give accurate line numbers, so please bare with me. Searching for site_id, you will find the following lines:

if ( $details->site_id != $wpdb->siteid )
  wp_die( __( 'You do not have permission to access this page.' ) );

These lines get commented out. Next, you should find:

$query = "SELECT * FROM {$wpdb->blogs} WHERE site_id = '{$wpdb->siteid}' ";

I replace this with:

$query = "SELECT * FROM {$wpdb->blogs}";

Then comes:

$query = "SELECT *
FROM {$wpdb->blogs}, {$wpdb->registration_log}
WHERE site_id = '{$wpdb->siteid}'
AND {$wpdb->blogs}.blog_id = {$wpdb->registration_log}.blog_id
AND {$wpdb->registration_log}.IP LIKE ('%{$like_s}%')";

replaced by:

$query = "SELECT *
FROM {$wpdb->blogs}, {$wpdb->registration_log}
WHERE {$wpdb->blogs}.blog_id = {$wpdb->registration_log}.blog_id
AND {$wpdb->registration_log}.IP LIKE ('%{$like_s}%')";

After making these edits, all my sites appeared on the super admin list and so far I have not found any other issues. Use these changes at your own risk. This has not been heavily tested. As time goes on, if I find more issues, I will pass on the information. These modifications will be used on some rather large sites once all my conversion is done, so the testing will happen. I will keep you informed.

Learning WordPress

With the data move complete, the next step will be theme creation. I am currently reading about WordPress in the book Smashing WordPress: Beyond the Blog from Smashing Magazine. I will post a full review later but so far the book has been good, though at times written a bit below my level (too simplistic). The information is good and that is what’s important.

Migrating from one system to another

My next project involves moving some sites from a now defunct application called Article Manager by Interactive Tools to WordPress. Since this also involves a redesign of the site, there is no need to translate the templates. This will be a data transition only.

Article manager creates flat files from its data. It is not a “live” system like WordPress is. The good part about that is the low database utilization and very quick serving site as all you need is a quick web server. The down side comes from the very limited template language the system uses. There are no variables you can create, very little branch control, very little state you can check. It was quick and relatively simple but in the end too simple for our needs. Interactive Tools has moved on from that product to one they call CMS Builder.

Article Manager (Artman) contains all its data in four tables, one for the articles, one for categories, one for users and one for what it called publish rules. The publish rules are instructions to the system on how the create the flat files. Since those are not needed in WordPress, I can ignore that table. That leaves three.

The first I will convert is the user table. I choose that one because it is referenced from the other two via creator ids and such. Second, I will move the categories and third will be the articles themselves. This will be the most interesting one and will take the most manipulation. I’ll need to update the user ids and category ids. I will also have to decode the way Artman stores image references for articles. Instead of keeping the original link to the images the way WordPress does, Artman had a code system for placing images into the article.

Since I will be doing this conversion more than once, I plan to build a tool to do the job. In the end, I will be combining many sites into one WordPress multisite install.

Cross posting with WP-United

Finally got around to getting cross posting working with WP-United. It was not too difficult once I got over the notion of having PHPBB handle the logins for WordPress. All that was needed was to mark the settings in WP-United to have PHPBB handle the logins, then you enable crossposting and comments. Once that is done, there are some permissions changes that need to be made in PHPBB. Usergroups need to have WP_United permissions added to allow cross posting and comments. Also, the forum into which things will be cross posted needs to be set permissions. That’s all there was to it. Very nice and easy.

Once it was working, there were some changes that needed to be made to the text that is generated for the cross posted items. Some of these changes are in the language file. That is found under the languages/en/mods/wp-united.php file (at least in my case where my forum is English) under your PHPBB install directory. The entries I changed were blog_title_prefix and blog_post_intro.

By default, WP-United puts the blog_post_intro first in the post, then some lines, then the post as either excerpt or full story as selected when cross posted. I wanted the link to the post, which is in the blog_post_intro after the story instead. To change this, I edited wp-united/functions-cross-posting.php. I searched for blog_post_intro in that file to find the relevant line to edit. It was a simple string concatenation and was real easy to change. Now the posts appear as I want.

Model160.com is almost ready to launch now. There are a few more stylistic things to change and there is some odd behavior from time to time that I think comes from WP-United. All those things are related to CSS so I am confident I can get them sorted out.

WP-United and Google sitemaps

This morning I discovered a problem with the Google sitemaps on my site. They were no longer being generated correctly. I’m not sure if that problem existed before I made a change to WP-United or not.

We wanted to have the URL to the site be simply http://www.model160.com and not the default of http://www.model160.com/forums/blog.php. That change was easy enough. All you need to do is copy /forums/blog.php to /index.php, edit the new index.php to add the location of your PHPBB directory, /forums in our case, and then change a setting in the WP-United panel. Once that was done, the site looked the same, which is exactly what I had hoped for.

The problem is, the setting for your home page in WP-United includes the file name, so it looks like http://www.model160.com/index.php in our case. I use a plugin for Google sitemaps called Google XML Sitemaps with qTranslate Support. The problem was it was grabbing the site URL from WP-United and so was attempting to generate the file as http://www.model160.com/index.php/sitemap.xml. Since index.php is not a directory, it didn’t work. All I needed to do was set the path manually to sitemap.xml and the url to http://www.model160.com/sitemap.xml and all was better.

WP-United

Yesterday I decided to take a different tact with the WordPress / PHPBB integration. I installed AutoMod into PHPBB and used that to install WP-United. This time, I had no issues. I remembered to deactivate all the plugins first which was probably the cause of my issues in the first place.

Not too much to talk about this time as the install worked exactly as I would have hoped it would. Things seem functional for now. As of now, I have PHPBB running inside WordPress. My next steps will be to figure out how to better integrate things and to try some of the cross posting features. I would also like to investigate using PHPBB as the comment system for WordPress.

WordPress and PHPBB integration

For a site I’m working on, I need to integrate PHPBB into WordPress. There are a few solutions for this out there but WP-United seems to be the one that is cited most. As such, it’s the first I’ll work on.

I attempted this integration last week with no success, but I must admit that I tried to rush it and should have taken a different tact. I got the PHPBB side uploaded and manually edited the files according to the install XML file. After getting all the files edited, I tried running the setup wizard and got lots of error messages. Most of the messages were about duplicate function definitions and a couple of duplicate class definitions. To fix these, I added if (function_exists("FUNCTION NAME HERE")) { blocks around the offending functions and if (class_exists("CLASS NAME HERE")) { around the classes. It was quite repetitive and annoying. So much so, I looked into creating macros for my favored editor jEdit. The macro worked well and saved tons of time, but the solution was a poor one for the real problem.

Once that was all done and the errors stopped showing, I tried the setup wizard again. The main way wp-united likes to work is to display WordPress within PHPBB. I wanted to go the other way as the site already had a lot of work done to change the appearance. I aborted the wizard and just filled in the settings on the settings page. In the end, something was not done correctly and the site and no longer functioned.

I think one of my critical mistakes was I did not disable my WordPress plug-ins before installing. Before editing the files the first time I had made a tar backup of the site, so I was able to get things working again pretty easily. I intend to try again, this time using AutoMod on PHPBB and disabling plug-ins before installing. As I write this, WP-United.com is not responding, so I am unable to try again for the moment. As soon as it is available again, I will retry the install.

I should note that I am using WordPress 3 on this site and WP-United is not yet updated for WordPress 3. There are some instructions for allowing it to run, but I expect some problems.