Tagged WYSIWYG

Shashin now has a WYSIWYG, or Is Mike Toppa a WordPress god?

I use the Shashin Picasa plugin for the photos on this site. I broke it today trying to upgrade my Tagline Rotator plugin, so I upgraded to the latest version of Shashin to try and get it working again (it did). After checking the version notes, I did a little dance–see, it used to be that you had to go into Shashin’s Tools page in your WordPress admin to get the unique ID associated with your Picasa photo in order to embed it. The main thing that attracted me to Shashin was the the wide variety of ways you can display photos, and the flexibility of the plugin to conform to different blog types, etc. However, while the notation used to insert a photo or a set of photos is simple and quick, having a WYSIWYG within the WordPress editor is very useful and a welcome addition to the plugin. I’d have to say that, for my purposes, Shashin is perfect and its author, Mike Toppa, deserves a good amount of praise for the work he’s done.

WordPress Widgets now available for download

The WordPress development team announced the release of the new Widgets feature today. The idea behind these Widgets is apparently that they allow you to edit your blog’s formatting and design (in this case the sidebar) through a GUI, eliminating the need for coding knowledge. Although I’m a bit afraid that, like the WYSIWYG editor which made its way into WordPress 2.0, the new Widgets might prove more cumbersome than helpful, I also think it’s important to look at the big picture of blogging as it exists today. There are hundreds of thousands of people out there with excellent blog content and the crappiest looking template imaginable, because they lack the knowledge to edit the source code directly. This tool will help them incorporate the little additions and gadgets that make the blogging experience enjoyable for the reader, without forcing them to spend countless hours debugging changes on multiple browsers and multiple OS’s. Additionally, since WordPress claims that writing Widgets should be as easy as writing plugins, the open source world should soon be contributing a plethora of them to match the output of plugins that we currently see. I know that it’s popular to hate things like this within the IT community, where obscure wisdom is prized as a status symbol, and the general attitude is ‘if you can’t do it the hard way, you’re not worthy of doing it at all,’ but if Widgets can help expand the two-way communication that thrives on blogs, more power to ’em.

Importing Macromedia Fireworks HTML into WordPress 2.0

To create the previous post, I obviously needed to incorporate some Fireworks HTML into WordPress 2.0‘s post editor in order to show the example. Having long since given up on the WYSIWYG editor that shipped with this new release, I started by trying various methods to get the image into the post by cutting and pasting various bits of HTML and JavaScript from the fireworks .html source file. The most important thing to remember is that you need to include Macromedia’s JS functions in the header of your theme, as high up in the code as possible, but at least before the CSS. What you’ll need looks like this:

<script language="JavaScript">

function MM_findObj(n, d) { //v4.01
var p,i,x; if(!d) d=document; if((p=n.indexOf("?"))>0&&parent.frames.length) {
d=parent.frames[n.substring(p+1)].document; n=n.substring(0,p);}
if(!(x=d[n])&&d.all) x=d.all[n]; for (i=0;!x&&i

So, with functions firmly in place, I began cutting and pasting some more. The main issues with this approach which quickly made themselves apparent were:

  1. By default, the ‘post’ lives on the blog‘s root level directory, but the billions and billions of tiny .jpgs which make up the actual Fireworks-produced rollover image live in whatever directory you put them. Updating the links does nothing, since the rollover behavior is governed by JavaScript, and a simple find/replace can’t help you there.
  2. Even when you decide you’re willing to dump billions and billions of tiny images into your root blog directory, the image shows up waaaaay down the post, for no apparent reason.

In light of these problems, I finally threw up my hands and decided I’d insert the image into a simple Dreamweaver html page, put it to the server, load the page in a browser, select all, and paste the whole mess into the WordPress editor, only this time with the WYSIWYG turned on. Lo and behold, it works perfectly, rollovers and all (assuming the page with the image you create is in the same directory as the Fireworks HTML and images, and that you’ve added Macromedia’s JavaScript to your header). The fact that the html looks exactly the same as it does when you painstakingly insert it into the html post editor by cut and paste notwithstanding, none of the spacing issues remain. Simple and easy, and finally, a justification (at least for me) for the WYSIWYG (which is back off for this post).