WP-United comes back to life!

It’s been a bit over a month that I’ve been reading about the resurrection of WP-United, but the day I’d been waiting for has come. A release date has been set for the newest version of WP-United. It will be released on the same day as WordPress 3.5, which is in two weeks. Jhong is asking for people to install the beta and give feedback, so if you have a site where you can oblige, please do so and help us all out!

wp_remote_post and Cookies

Learning about wp_remote_post

In the beginning I was’t using wp_remote_get or wp_remote_post. In my Piwigo Embed plugin, I was doing some HTTP requests to get the gallery output to place inside a WordPress page. The intent was to be able to skin Piwigo independently from WordPress. I wanted the Piwigo content within the WordPress theme without having to recreate the look specifically for Piwigo. I was doing the requests using file_get_contents for GET requests and fopen for POST requests. It worked well for my purpose. I took the output and manipulated the URLs in links and for images and then spit the contents to a page using a shortcode.

This solution worked fine for me. I had control of the execution environment, so I didn’t have to worry about configuration not allowing fopen on URLs or anything like that. Then I saw and article about the WordPress wp_remote_get, wp_remote_post, and wp_remote_request functions. This seemed a much better solution to me. I prefer to use built-in tools if I can and these functions take care of the execution environment differences and would allow me to treat the get and post requests more similar to each other. I started modifying my code.

The Problem

I ran into trouble very quickly. Piwigo needed a cookie set in order to access the admin functions. I tried setting the cookies as an associative array of cookie_name => cookie_value and sending that with my request. This failed. I then tried a simple array with name then value and this failed. I kept getting the error: Fatal error: Call to a member function getHeaderValue() on a non-object. I looked around to find a solution to this problem but could not find one.

The Solution

The documentation on this subject is poor in the WordPress Codex. It is mentioned that cookies are sent in the arguments associative array to the request, but the form of those cookies is not specified. It only mentions that the cookies need to be in an array. Then, I stumbled across this link and the answer was clear. The cookies needed to be set as objects of type WP_Http_Cookie. There is no mention of the WP_Http_Cookie object in the description of the wp_remote_get, wp_remote_post, or wp_remote_request functions. I also did not find it referenced in the articles I found online about these functions. It is because of the obscurity of this information that I write this post. I hope others will be spared the issues I ran into.

So the solution to the problem: If you need to send cookies with your wp_remote_get, wp_remote_post, wp_remote_request call, create the cookies at WP_Http_Cookie objects, add them to an array, and send them in the arguments labeled as ‘cookies’. Once I changed my code to use the WP_Http_Cookie object, it all worked fine. Hope this helps and happy coding!

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.


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.