ACHTUNG!
The Markdown Image Hack has been retired. Please check out Lazy Image Layout instead!
The code has been separated from Markdown, and is now a stand-alone plugin called LazyImages.
Continuing with the markdown/pictpress hack, this post with serve as a to-do / issues list.
Download MDIH 0.3, the MDIH 0.3 changes, or follow the development history.
In version 0.2, note that the syntax has changed, so you will have to update your old posts if you were using 0.1. But no one was, so I doubt it will be a problem :-)
done I want to add a special popup value for the link url, which would automagically put the full size image in its own tasty window. I'm not sure where I would insert the javascript code for this in a portable way. For all I know, there is built-in javascript already in WordPress, so I should do some more digging.
done What about GIFs? So far, this is JPEG only! I can either snoop the file's extension, or maybe there is some kind of "magic number" routine that can identify filetype in PHP. That would save me some string processing work :-)
fixed I just realized that I have the syntax kind of backwards. I should put the link as the second parameter, and have all the image control in the first link. This came to me when I found myself wishing I could use the global link defs in markdown. Maybe something like...
!@[image_uri](url "title")(L 120)
!@[image_uri][id](L 120)
...where the parameters get their own little extension parens. I think I can write a regex that treats that last as optional, and it can default to a standard left-justified thumbnail. Or maybe I don't use regex at all on the individual backreference level and just get the entire match, and EXPLODE it. That would make life easier :-)
done Use global link defs, because I love 'em.
done It would be useful to have a CLEAR ALL indicator. The half-assed way I'm designating alignment (due entirely to my weak grasp of regular expressions) could be extended to support this, perhaps by using lower-case to mean "float" and upper-case to mean "clear, then float".
handled The way alignment and width are glommed together is because I wasn't sure how to handle extra or out-of-order parameters gracefully using regular expression references, so I put them into one thing. Since they are all required, though, I could just have a separate alignment parameter. Though I kind of like them as one thing. I don't want to require too many parameters, because that defeats the purpose of Markdown.
If I use syntax changes, I could introduce longer keywords, but that gets away from the spirit of markdown. Maybe L for left float, and LB for left float break?
Put a quick upload form on the Write and Edit admin pages, so they are automatically uploaded to the right directory? It should be possible to hook into the post page, since I've seen other plugins claim to do it. This would simplify uploading, especially if the upload manager automatically uses the post_id to create a containing directory. That would totally rock. The links inside the markdown syntax could probably just access files by name, and you'd never have to use a directory again.
done Change the cache file naming scheme so cache comes FIRST in the name. I thought at first that I wanted files to sort alphabetically so related files were in a nice block, but that kind of sucks when you are looking for just the important originals. Also, put them in their own directory.
I've noticed that certain plugins seem to cause WordPress (WP) to run slower. PictPress, for example, seemed to slow down page generation by quite a bit. However, it might just be that the server load on the weekend is lower.
Still, I'm curious how to optimize WP, or to find out what's slow. A couple of tips to speed up performance I found:
- limit # of posts shown per page
- don't use posts-per-category counting
- hardcode links
- use xcode or some other profiler to find out where all the execution time is goin
- don't use the cgi version of PHP. Though my host's customer support said it shouldn't be slower when I asked before. lies?
The gist of this seems to be: limit the number of database queries and text processing as much as possible.
ACHTUNG!
The Markdown Image Hack has been retired. Please check out Lazy Image Layout instead!
The code has been separated from Markdown, and is now a stand-alone plugin called LazyImages.
The Markdown Image Hack has been retired. Information here is for historical interest.
I can now insert images using my own hacked version of Markdown 1.0's inline image syntax. Yay! I love Markdown, because it allows me to avoid using actual HTML tags in my posts. However, its inline image support was quite basic.
The modification I've done allows me to type:
!@[images/boogah.jpg](index?p=36 "juicy!")(L120)
...instead of...
<a class="image-left" title="Juicy!"
href="index.php?p=36">
<img src="/wp-content/images/boogah-120.jpg"
width="120" height="133" alt="Juicy!" />
</a>
!@images/test1.jpg( L100)
So what's the big deal, you ask? Markdown already has image support, but it doesn't support width or additional formatting. And personally speaking, it's also my first dabbling into the WordPress' plugin architecture and PHP coding. It was also a painful re-union with regular expressions, of which Markdown makes heavy use in the course of doing its texty magic.
!@images/test2.jpg( R100)
As much as I like PictPress, I still wanted more flexibility in placement of the images, and I wanted to be able to add text to individual pages for my portfolio. PictPress was almost there, but not quite. I realized that I could achieve the same functionality manually by just using the
more and nextpage tags. One feature I wanted, though, was the automatic image caching, because it makes file image management less of a hassle...I hate cutting thumbnails!
I'm pleased that this hack mostly works and looks pretty good, though I am wondering how I might have implemented this cleaner. If you're curious read on, or skip to the downloading part
The Lowdown
While Markdown does have inline support for images already, I wanted something that produced some nicer thumbnail layouts. I also liked the idea of automatic thumbnail creation, which is something PictPress does. So I started with the Michel Fortin's port of PHP-Markdown, and starting chipping away.
!@images/test2.jpg( R50)
!@images/test1.jpg( L50)
The code I added to Markdown creates cached files of the name origname-nnncached.jpg, where nnn is the width in pixels, and stores them in the same directory as the original uploaded file. This automatic resize-and-cache was inspired by PictPress' resize.php code, though I'm using it within the Markdown code itself instead as a replacement for img src. I also decided not to create a separate cache directory, figuring I could use recursive rm commands instead to purge when I needed to.
!@images/test2.jpg( R160)
!@images/test1.jpg( R80)
The general approach I took was to look at Markdown's code to see where its inline image parsing was. This was illuminating because to that point, I didn't really know how WordPress worked. WordPress 1.2 plugins can make many many passes at the text for every page view request. Wow. I see the advantage of the static Movable Type system here...rebuilding your MT site may suck for immediate gratification, but the tradeoff is loading down the server. I've noticed that this site is a bit sluggish to load already (but I am also using phpcgi on my host so files are created under my uid).
!@images/test3.jpg( N450)
For the centered image, my layout maxes out at 450 pixels. I made a centering attribute, but it probably wouldn't actually center for anything less than 450 pixels; the reason for having a 'C' attribute is so the image-center class doesn't add margin on the left and right. Yeah yeah, I'm fussy.
The Hack
In the PHP-Markdown code, I duplicated the _DoImages() function and made a new variation called _DoCachedImages(). These functions handle the parsing for the image syntax. I had originally tried to extend the _DoImages() functionality with the existing syntax, but didn't realize it was broken in the 1.0b4 version that shipped with my install of WordPress. After getting the latest version, I still wasn't sure what the best way to handle having two optional parameters in a regular expression, so for the sake of limiting damage to core functions, I split out my own routine.
Markdown does a lot of interesting things to ensure its simple markup language works in the context of an xhtml-compliant page, so there is a particular order to how things are done. Most of it I have not yet grasped, so I inserted my own call to _DoCachedImages() right next to the original _DoImages() call in _RunSpanGamut().
A consequence of doing it here are "block-level formatting" conflicts. Markdown has already created wrapping paragraph tags at this point, so that means you can't insert divs with any of the inline markup. I couldn't figure out how to scan and create block-level hash keys from markdown syntax, so I went with a simpler thumbnail layout that just uses borders and padding. So no nice PictPress dropshadows :(
As for _DoCachedImages() itself, all it does is handle my variation on the inline image syntax. At the time the filter is invoked, it will know the URL for the A tag, and the relative URI for the image, and the requested size and alignment. This is everything needed to emit the proper bit of html.
Some decisions I made:
The URI for the image is always the one you uploaded to your wp-contents folder, no matter what size you've specified. _DoCachedImages() generates the thumbnail files and substitutes the appropriate thumbnail URI for you. The idea is to not have to worry about the names of thumbnails at all. You also don't have to include wp-contents in the URI, because we will always assume you've uploaded there.
There are three kinds of alignment: L (left), R(right) and N(center, no margin). They are case-insensitive, and part of the requested thumbnail width. So a "right aligned 250pixel thumbnail" is expressed as "R250". If you leave out the parameter, the code is supposed to show the full image, but that doesn't really make sense so I may change that.
The alignment letters are used to output the HTML using different CSS classes that you can define in wp-layout.css. The CSS is unremarkable-they just have different padding and margin values set-but they're exposed if you want to sex them up. Here's an example:
a.image-left {
float: left;
margin: 4px 16px 8px 0px;
}
a.image-left img {
display: block;
border: 1px solid #9999aa;
background-color: #fff;
vertical-align: text-top;
padding: 4px;
}
There is probably a better way of doing this...I'm a CSS novice, no relation at all to guru Dave Shea.
:: Continued in Inline Image Hack
I really like the Markdown plugin in WordPress, particularly the cool reference style links. As someone who still uses a plain-text email client, it's no surprise that I'd appreciate the simple syntax of Markdown...I already use it!
Still, since I can't leave a good thing alone, I'd like it to work with my uploaded images, wrapped in fancy dropshadow boxes. So I'm going to try hacking in some of that goodness using some of PictPress's features.
PictPress, while very nice for thumbnail galleries, doesn't quite offer the control I want. Plus, it pollutes my posts with extra tags even when there are no images to add, offers no ability to position thumbnails anywhere else but at the bottom of the entry, and doesn't play nice with my admittedly crude CSS manipulations. So I've disabled it, and have regained manual control.
PictPress has very nice bit of code in it: the resize.php script that automatically generates and caches thumbnail size images.
What I'd like to do is extend Markdown's image linking to use PictPress's thumbnail & image presentation, combined with on-the-fly caching.
* I'd like to just upload ONE full resolution image to any valid directory, then put in the link in with Markdown.
* I'd like to add a couple of extensions to its syntax for WIDTH and ALIGNMENT.
* I'll let Markdown pick the name of the thumbnail and retain its cachedness by stuffing it right back in the same folder as the original uploaded image.
RANDOM NOTE: Is it my imagination, or does my site load much faster with PictPress disabled?
