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!
Light Table: A Glimpse at Programming’s Future
It appears I wasn’t the only fan of Bret Victor’s talk and the possibilities of the tools he described. Chris Granger took the notions and ran with them to create a Clojure IDE called Light Table. It doesn’t look like the IDE is built specifically for Clojure, but that was his language of choice. Light Table is an interactive draft table for the programmer. That’s the best way to describe it. It gets out of the way, makes documentation and code easier to see, read and find. It has the dynamic execution described by Bret to encourage exploration and help find bugs before they cause problems. This tool looks amazing! It’s a first step in what should be a new breed of programming editor.
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.
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 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!
My Problem with Mobile Safari Centering Content
I ran into an issue with one of my sites and had difficulty finding the solution spelled out so I figured I’d write about it here. I could not get Mobile Safari centering content correctly. The page worked fine in Safari, IE, Firefox, anything I tried on Mac or PC, but on mobile Safari centering content failed.
I decided to try experimenting to see if I could replicate the problem, and I very easily did. From my experimenting, I found when content was larger than 960px wide, I could not center other content that was narrower. In my case, I had a wide top image and a 960px content column in the bottom. In Mobile Safari, that content below the top, wide image would left align. It would left align wether I centered using margin auto on the left and right, or used the left 50% and negative 1/2 with left margin centering option. Both these solutions worked elsewhere.
A ‘duh’ moment
Earlier in my development of this page, I had set the meta viewport to be 960px. I think at the time the top portion of the page was going to be that width. It appears that may have been partially to blame. The solution is to set the meta viewport to the widest content. Once that was done, centering worked exactly as expected. In my reading, I think the tipping point width is actually 980px, but I have not verified that. I should mention that my simple recreation of the problem did not have the viewport set initially, so it being set low was not really the issue. It needs to be set correctly.
So, the lesson is if your site is wider that 980px, set the meta viewport to the width. It’s probable best to always set the viewport to the proper width, but if your site is wide, it’s essential.
Things have certainly been keeping me on my toes lately. My sites have had two different hacks aimed at them in the past couple of weeks and the sites I’m working on at my job are finally nearing launch. I’ve been doing lots of reading lately and should really document more of what I’ve found here. Blogging is pretty low on my priority list at the moment and it’s unfortunate because I do think I could help some people if time permitted.
I have done no additional investigation into WP_United in months. I will look at it again once things calm down here a bit. I believe I have found the answer to my remaining problem with the Piwigo embed. I had to solve a similar problem with a gallery software called EmAlbum and found the answer there. Just need to port it back to Piwigo. That will be happening within a few weeks.
Been doing more investigation into SEO in general and some specific implementation details. This is another area where I need to share what I find, and hope to after these launches are complete.
That’s a quick overview of my recent developments. If you watched the video I posted by Bret Victor, you might also be interested in visiting his site. He has lots of interesting things to see there, plus lots of interesting transitions and such for his content. Worth look at.
This is a real impressive video. I can only hope someone acts on it and makes the tools he is outlining! I would LOVE to work with those tools!
I haven’t done very much marketing or SEO on any of my sites. I’ve been too distracted writing code and creating themes in a vacuum and should probably keep up a bit more on my reading. In any case, I was alerted this article on Yoast by a colleague and have gone through the trouble to implement it on one of my sites. One nice thing is the Twentyeleven theme in WordPress takes care of the rel=”author” on the author tags already. The rest is still a manual job.
Since I am using the Twentyeleven theme, I didn’t want to edit the templates. That always gets messy when the theme is updated. In the case of my other site, I created a sub-theme to allow me to make some of the changes easily. I’ve kept my changes contained to the functions.php file thus far.
At the moment, I haven’t made the same changes to this site. I will do that when I get some time. I would also like to create a ground-up custom theme for this site and my other sites, but once again, time is the issue.
Over the next few weeks, I will monitor the stats to see if these changes drive any additional traffic my way. I’ll report findings here if I have any.
At CES, ION has announced a dream come true. I thought the original iCade was the answer to this dream, but the iCade Jr. proves me wrong. As a kid, I saved for months to but a miniature arcade cabinet game. The one I bought was Frogger. At the time, it cost $50. That was quite a lot for me to save. Later, I was able to get a second cabinet from a garage sale for something like $5 or $10. That one was Pac-Man. I enjoyed those things at the time, but of course they fell short of what I wanted in my mind, which was the arcade game as I knew it, but small and in my bedroom with my other toys.
Now, the iCade Jr. is exactly that, and even better being smaller than the original concept. I’ve played with the original iCade and it was a smooth experience, though setting up the games can be tiresome on the Atari app. In that app, you need to tell each game if the iPad is horizontal or vertical separately. Seems like something they should have been able to fix. Anyhow, I can’t wait till this thing comes out. I need this on my desk to distract me from programming!
I originally saw this on MacRumors.com where the above photo comes from their CES coverage.
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.
I have chosen a less dramatic title for my post than Business Inside did for theirs, but the talk is quite good and the ideas quite interesting. Roger McNamee is an investor and a musician. He seems to actually like technology and wants to see good uses of technology. Business Insider decided to highlight the quote “social is dead” in their title, but the talk is not much around that. His meaning of “social is dead” is that it is expected and maturing rapidly and thus new social start-ups are likely a waste. His suggestion is to focus efforts on HTML5 based experiences that are at least as good as what you can do on an iPad app. You can see his talk below.