Edit a Wordpress Article with PHP and XML-RPC
Sunday, May 9. 2010
I had created a topic discussing how to create an interface to add new posts to a Wordpress blog using PHP and XML-RPC. It was something I had needed for work. Unfortunately for many of my site visitors and readers from Google, I never had the need to edit an article, but many of them did. I no longer had a development installation of Wordpress and I don't particularly like Wordpress (due to its spaghetti like codebase).
The people have spoken though, and I have listened. I reinstalled Wordpress to see if I could get an edit action to work. This is a two step process, you must first get the contents of the post, and then submit the edited version back to Wordpress. The tricky part here is modifying the date field.
If you haven't read my first post on adding a new post in Wordpress with PHP and XML-RPC, you'll want to read that. There I cover all of the basics you would be better off knowing before tackling an edit straight from this code (it won't make much sense otherwise).
Using the same IXR library that I used in the post creation article, we'll use a similar approach to retrieve an article. There are two ways to get article information - if we know the ID of the article we can simply use metaWeblog.getPost, or we can get a list of recent posts (with a maximum limit of - I believe - 15) using metaWeblog.getRecentPosts.
A simple print_r() of $request will give me the following:
As I said, the tricky part here is the date. If we want to modify the date, we need to supply the IXR_Client object an IXR_Date object. But how do you do that? Well, looking at the IXR class code, the constructor needs to be supplied either an ISO date, or a timestamp. Since it's easy to supply a timestamp, I'll do that for this example.
I used strtotime() with "now" as the passed parameter so that we'll get back a timestamp for the current time. This is just an example, make it fit to your needs. I've also put in the necessary data required for the $content variable, and used most of the variables from the previous metaWeblog.getPost request. So...now we simply call the actual query for metaWeblog.editPost:
That's it. metaWeblog.editPost is pretty easy as long as you have the right data being sent to it.
Note: I will NOT be indulging questions pertaining to anything beyond the scope of this article, such as custom fields or any type of plugin that modifies the standard behavior.
The people have spoken though, and I have listened. I reinstalled Wordpress to see if I could get an edit action to work. This is a two step process, you must first get the contents of the post, and then submit the edited version back to Wordpress. The tricky part here is modifying the date field.
If you haven't read my first post on adding a new post in Wordpress with PHP and XML-RPC, you'll want to read that. There I cover all of the basics you would be better off knowing before tackling an edit straight from this code (it won't make much sense otherwise).
Using the same IXR library that I used in the post creation article, we'll use a similar approach to retrieve an article. There are two ways to get article information - if we know the ID of the article we can simply use metaWeblog.getPost, or we can get a list of recent posts (with a maximum limit of - I believe - 15) using metaWeblog.getRecentPosts.
A simple print_r() of $request will give me the following:
As I said, the tricky part here is the date. If we want to modify the date, we need to supply the IXR_Client object an IXR_Date object. But how do you do that? Well, looking at the IXR class code, the constructor needs to be supplied either an ISO date, or a timestamp. Since it's easy to supply a timestamp, I'll do that for this example.
I used strtotime() with "now" as the passed parameter so that we'll get back a timestamp for the current time. This is just an example, make it fit to your needs. I've also put in the necessary data required for the $content variable, and used most of the variables from the previous metaWeblog.getPost request. So...now we simply call the actual query for metaWeblog.editPost:
That's it. metaWeblog.editPost is pretty easy as long as you have the right data being sent to it.
Note: I will NOT be indulging questions pertaining to anything beyond the scope of this article, such as custom fields or any type of plugin that modifies the standard behavior.
SWFObject 2.x and Zoomify
Tuesday, May 4. 2010
Zoomify is a software company/product that allows for continuous zooming on extremely large image data (JPEG2000) by first separating the original image in to many parts, and then using Flash (and XML) to dynamically piece them together again within a viewer. It works quite well (you can see an example from their website). They have a free "express" version; a version that comes bundled as part of Adobe Photoshop (CS3 or above - File -> Export -> Zoomify); a version that allows you to modify the look and feel of the view with XML (retail product), a version that contains the FLA source code (retail), and their flagship product, the Enterprise version which allows you to house everything necessary for simplistic creation all on the server...including everything all of the other versions offer, as well as more features and the ability to simply upload images directly to the server for parsing.
SWFObject is a JavaScript utility used for dynamically (or statically assisted) inserting of Flash media to a web page. If a user does not have Flash (or the correct version), it will automatically prompt them to download and install it. If they do not have JavaScript enabled, whatever content you were originally going to replace with the JavaScript will simply show instead. It also is unobtrusive, is Adobe's recommended way of embedding Flash to a web page, and has been time-tested to cover many edge-cases of its use.
Zoomify is a great tool to use in places where fine detail is needed to be viewed, but either a slow connection or speedy access is required to the content (plus, who wants to wait over 30 seconds for an image to load?). With working in a library, I've found it's an excellent tool for displaying historic images - such as digital archives. These high resolution images are not really useful in a regular web-centric view, but once you add the ability to zoom in to see detail, such as a person's face from something which was originally a 1.5"x3" panoramic scene - well, even I was in awe. ...and it's quick!
The problem with Zoomify is that by default, the free tools (for download from their website, or the one included in Photoshop) export an HTML page with EMBED and OBJECT tags directly in the HTML. If you work for a local/federal government or state owned library in the US, you are legally obliged to follow standards, and the EMBED tag is not an HTML standard and therefore breaks standards compatibility. What to do? Use SWFObject - it dynamically inserts the necessary code to get your browser to render the Flash movie on the page. Unfortunately, there's little information (if any?) on getting Zoomify to work with SWFObject out there on the web. Before I discovered I had a typo in my code, I emailed Zoomify support to ask about it and they emailed me back with Adobe's own version of AC_RunActiveContent.js - however Adobe recommends the use of SWFObject over their own JS implementation. I intend to thank Zoomify for trying, and giving them a link to this article entry. After all, they're more specialized as Flash developers so I can't fault them and their product really does seem to be the best (perhaps they accidentally attached the wrong project archive, who knows). Microsoft's Seadragon claimed to be revolutionary, and I had already been using Zoomify for about a year, and Zoomify felt more responsive and more people use Flash. Oh well, Microsoft. It's still cool.
Sorry for my rambling, on to some substance.
Zoomify provides the following HTML code by default in the HTML template that it creates for you:
So ignoring all of the classid, codebase, and other junk we don't completely care about, let's look at the actual values being passed to the browser through the PARAM tags within the OBJECT tag. These are the values we'll need to pass to SWFObject.
SWFObject separates its value passing to two variables, flashvars and params. FlashVars, found above, is its own PARAM variable, containing multiple values URL encoded. In this example, we have the variable zoomifyImagePath with a value of "example_img", and zoomifyNavigator set to false. The navigator is a small box that hovers over your image (full opacity) showing where you're viewing within the overall aspect of the original image. That takes care of the flashvars values, not to the params which is everything else. bgcolor is, of course, the background color for the flash stage, which will be covered up by your image data, so you can optionally ignore it if you'd like. menu...to be honest I don't know what this does, I changed the values and saw no difference and even removed it. src is the source, or location of the Zoomify viewing flash application that is used to actually view your data. This is a relative path to your viewer file. If you will be using this script in more than a single place on your website, I strongly recommend you only use one viewer and point all of them to that single viewer. Also notice the HEIGHT and WIDTH attributes to both the EMBED and OBJECT tags here. You can change them if you don't care about standards support and SWFObject, but they must match.
So how do we set up SWFObject with the knowledge now in our hands? Well, let's take a look at a standard (dynamic) SWFObject call.
So going from the example there, and the data we've collected, it seems pretty simple! But wait, what exactly is the zoomifyImagePath? Should that have some sort of file extension? Well, no, and that's what threw me, honestly (quite silly, really). The Flash file knows to look for the XML file in the folder that you're telling it to look in, so all you need to do is send the location of the folder (relative URL) and it'll do the rest. So let's see what that would look like:
The flashvars and params variables expected by swfobject.embedSWF are JavaScript objects, not simple variables (or rather, variables with object notation) as the variables themselves hold variables.
That's it. Keep in mind that the example above didn't use the bgcolor, or menu values. I also didn't use the "attributes" variable that can be passed to SWFObject where you can define the id, name, class, and align values. It's unnecessary for this example so I skipped it, as is showing a callback method (unnecessary that is).
Mix that together with a little modal magic and you have something a little bit nicer, such as what I did in the following page:
Honoring Saratoga County Veterans
Enjoy!
SWFObject is a JavaScript utility used for dynamically (or statically assisted) inserting of Flash media to a web page. If a user does not have Flash (or the correct version), it will automatically prompt them to download and install it. If they do not have JavaScript enabled, whatever content you were originally going to replace with the JavaScript will simply show instead. It also is unobtrusive, is Adobe's recommended way of embedding Flash to a web page, and has been time-tested to cover many edge-cases of its use.
Zoomify is a great tool to use in places where fine detail is needed to be viewed, but either a slow connection or speedy access is required to the content (plus, who wants to wait over 30 seconds for an image to load?). With working in a library, I've found it's an excellent tool for displaying historic images - such as digital archives. These high resolution images are not really useful in a regular web-centric view, but once you add the ability to zoom in to see detail, such as a person's face from something which was originally a 1.5"x3" panoramic scene - well, even I was in awe. ...and it's quick!
The problem with Zoomify is that by default, the free tools (for download from their website, or the one included in Photoshop) export an HTML page with EMBED and OBJECT tags directly in the HTML. If you work for a local/federal government or state owned library in the US, you are legally obliged to follow standards, and the EMBED tag is not an HTML standard and therefore breaks standards compatibility. What to do? Use SWFObject - it dynamically inserts the necessary code to get your browser to render the Flash movie on the page. Unfortunately, there's little information (if any?) on getting Zoomify to work with SWFObject out there on the web. Before I discovered I had a typo in my code, I emailed Zoomify support to ask about it and they emailed me back with Adobe's own version of AC_RunActiveContent.js - however Adobe recommends the use of SWFObject over their own JS implementation. I intend to thank Zoomify for trying, and giving them a link to this article entry. After all, they're more specialized as Flash developers so I can't fault them and their product really does seem to be the best (perhaps they accidentally attached the wrong project archive, who knows). Microsoft's Seadragon claimed to be revolutionary, and I had already been using Zoomify for about a year, and Zoomify felt more responsive and more people use Flash. Oh well, Microsoft. It's still cool.
Sorry for my rambling, on to some substance.
Zoomify provides the following HTML code by default in the HTML template that it creates for you:
So ignoring all of the classid, codebase, and other junk we don't completely care about, let's look at the actual values being passed to the browser through the PARAM tags within the OBJECT tag. These are the values we'll need to pass to SWFObject.
SWFObject separates its value passing to two variables, flashvars and params. FlashVars, found above, is its own PARAM variable, containing multiple values URL encoded. In this example, we have the variable zoomifyImagePath with a value of "example_img", and zoomifyNavigator set to false. The navigator is a small box that hovers over your image (full opacity) showing where you're viewing within the overall aspect of the original image. That takes care of the flashvars values, not to the params which is everything else. bgcolor is, of course, the background color for the flash stage, which will be covered up by your image data, so you can optionally ignore it if you'd like. menu...to be honest I don't know what this does, I changed the values and saw no difference and even removed it. src is the source, or location of the Zoomify viewing flash application that is used to actually view your data. This is a relative path to your viewer file. If you will be using this script in more than a single place on your website, I strongly recommend you only use one viewer and point all of them to that single viewer. Also notice the HEIGHT and WIDTH attributes to both the EMBED and OBJECT tags here. You can change them if you don't care about standards support and SWFObject, but they must match.
So how do we set up SWFObject with the knowledge now in our hands? Well, let's take a look at a standard (dynamic) SWFObject call.
So going from the example there, and the data we've collected, it seems pretty simple! But wait, what exactly is the zoomifyImagePath? Should that have some sort of file extension? Well, no, and that's what threw me, honestly (quite silly, really). The Flash file knows to look for the XML file in the folder that you're telling it to look in, so all you need to do is send the location of the folder (relative URL) and it'll do the rest. So let's see what that would look like:
The flashvars and params variables expected by swfobject.embedSWF are JavaScript objects, not simple variables (or rather, variables with object notation) as the variables themselves hold variables.
That's it. Keep in mind that the example above didn't use the bgcolor, or menu values. I also didn't use the "attributes" variable that can be passed to SWFObject where you can define the id, name, class, and align values. It's unnecessary for this example so I skipped it, as is showing a callback method (unnecessary that is).
Mix that together with a little modal magic and you have something a little bit nicer, such as what I did in the following page:
Honoring Saratoga County Veterans
Enjoy!
