WordPress Plugins from OutlyerNet

Download v1.5 (last update october 14th 2007).

Relative URLs is mainly targeted at people with a local copy of their WordPress site and those that reorganise and/or change their pages hierarchy often although many standard installations can also take advantage of it.

Relative URLs can be seen as kind of complementary to Interlinks: It creates a valid URL or link from a relative path.
If you want to link to a post Interlinks or Interlinks+ are better alternatives, but if you want to link to a given file in your site neither will help you.
I guess so far it isn't clear what's the need for such a plugin, so let's clarify a bit, note that:

• Pages can be accessed from more than one URL (I'm assuming your WordPress installation is in a subdirectory and URL redirection is being used):
  • http://example.com/parentpage/page/
  • http://example.com/wordpress/parentpage/page/
  • http://example.com/wordpress/?page_id=2
• Using an absolute URL to refer to stuff in the site has the potential of being broken if you
  • Change WordPress' path, e.g.: http://example.com/wordpress/ is moved to http://example.com/ or http://example.com/blog/.
  • Change your (sub)domain, e.g. http://example.com/ becomes http://blog.example.com/.
• Using a relative URL to refer to stuff in the site has the potential of being broken if you (or visitors)
  • Access from a different URL, e.g.: A relative URL like images/im.jpg will point to different things when accessed from http://example.com/parentpage/page (http://example.com/parentpage/page/images/im.jpg) and http://example.com/wordpress/?page_id=2 (http://example.com/wordpress/images/im.jpg).

Finally, if you use a local copy of WordPress to test stuff, chances are your local copy would have quite a different URL, e.g. http://localhost/~username/wordpress/ and you might want your URLs to point to the local copy and not the on-line site.</p>

Download v1.0a+ (last update october 13th 2007).

Interlinks+ is based on Interlinks by Harley. The original adds a very nifty feature: it enables wiki-style interlinks (e.g. [[Some article]] will be converted to a link to the post/page titled "Some article").

There's a feature I missed in Interlinks: Support for piped links; continuing with the above example, [[Some article|That's a nicer title IMHO]] would link to "Some article" but the link text will be "That's a nicer title IMHO".

Additionally I added a couple extra modifications to generate valid XHTML, and made the link also display the article's title.

Let's compare Interlinks and Interlinks+:

<a href="http://example.invalid/my-article/">My article</a>

<a href="http://example.invalid/my-article/" title="My article">My article</a>

<font color='red'>My article</font>

<a href="http://example.invalid/my-article/" title="My article">My first article</a>

<font color='red'>Broken</font>

<span style="color:red;">Broken</span>

Enclose your local URL in double braces (e.g. {{myrelative/url}}), to get a full URL generated dynamically, e.g. to http://example.com/wordpress/myrelative/url.

Enclose your local URL in double braces along a text description (separated by a space) to get a dynamically generated link to the full URL.
{{the_url/file.txt The text file}} would become <a href="http://example.com/wordpress/the_url/file.txt">The text file</a>.

Note you'll have to encode any spaces in the url (e.g. to link to “the file”; you'll have to encode the space (replace it with %20) i.e.: {{the%20file}}.

If you want to write literal double curly brackets ({{) then you'll have to use an html entity such as { and } (or { and }). For maximum security use at least one on each end, e.g. {{ whatever }} will be parsed correctly as {{ whatever }}.
BUT beware of the visual editor in WordPress (although if you use it you're probably used to fight it ;).

Download v1.0+0.9a (last update october 24th 2007). (Note <var>1.0</var> is the plugin version and <var>0.9a</var> is the Base2 version used in the plugin).

A completely trivial plugin that loads Dean Edwards base2 JavaScript library (see [1] and [2]).

This library is mostly a cross-browser fix of the DOM plus a selectors API implementation (allowing selection from JavaScript with CSS selectors).

Note It is used by the following plugin :)

Download v0.2 (last update october 25th 2007).

This plugin loads Alex Gorbatchev http://code.google.com/p/syntaxhighlighter/SyntaxHighlighter JavaScript script. With a twist :)

SyntaxHighlighter is a script that will highlight code from JavaScript when marked appropriately, hence allowing you to post raw code that will be automagically pretty-printed on load.
I needed a couple workarounds to use it on my site and they were the motivation for this plugin:

First problem: Code must be enclosed in either a <pre> or a <textarea> tag, with their name attribute set to certain (user-selectable) value.\ The problem is, <pre> has no name attribute so the page wouldn't validate.
  My solution: (Note I opted to not modify SyntaxHighlighter code) Mark code with a class and then, on-the-fly, add the name attribute from JavaScript (this makes the HTML validate as the invalid attribute is only created in-memory).

Second problem: Each supported language has its own associated JavaScript file which you should load when writing code for that language. I felt loading them site-wide was was overkill (and I don't know which languages I might need), while loading them as needed, in the article body, felt cumbersome.
  My solution: Load the common script, see if any languages are needed and load them dynamically. As a side effect the page will load faster (the required languages are loaded after the page ended loading).

So in short this plugin loads SyntaxHighlighter allowing your pages to validate and only loading language files as needed.

I also changed the CSS file a bit to use fonts I consider look better and added colours to functions and variables.

Plugin installation:

1. Decompress in the wp-content/plugins folder, it will create its own folder.
2. Activate it from WordPress' admin panel.

Syntax highlighting:

1. Wrap your code in a <pre> or <textarea> with class syntax-highlight and the appropriate class for the language of the block, e.g. cpp for C++ (see the full list).
2. There's no step 2 :P But remember the highlighting takes place a bit after loading the page.

I dropped support for such a situation. You can try with an older version of loader.js but keep in mind that then languages won't be autoloaded.

Passing options for a block to SyntaxHighlighter needs a workaround as my loader won't detect the language then, the workaround is to use a hidden, empty block without options, i.e:
If you want to have something like

<pre class="syntax-highlight javascript:firstline[10]">
function doSomething() {
}
</pre>

PLEASE NOTE This is not an actual representation of the plugin in action. This page doesn't use SyntaxHighlighter.

Then you'll need to add a hidden block with the language class(es) needed. That block can have the classes of all needed languages:

<!-- Hidden, meaningless, code block -->
<div style="display:none !important;">
	<pre class="syntax-highlight html cpp"></pre>
</div>

Due to the way the code is written the following language name aliases won't be looked for (all of them have alternatives): c++, c#, vb.net.

They could be enabled with some escaping but I didn't feel the need :p

There're a couple things you might want to tweak, to change them edit the file loader.js (note that the version actually loaded in the browser is the one in the js/ directory, but it is shipped packed with Dean Edwards' packer, which makes it quite harder to edit. I suggest you to edit the version in the full-js/ directory and once you're happy with it pack it again.

bloggerMode: false,  // Set to true if the blogging software adds <br />'s
                     // See: <http://code.google.com/p/syntaxhighlighter/wiki/BloggerMode>
opts: [              // Options for HighlightAll, see <http://code.google.com/p/syntaxhighlighter/wiki/HighlightAll>
        true,        // Show Gutter
        false,       // Show Controls (!*not default*)
        false,       // Collapse all
        1,           // First line
        false        // Show columns
    ],
WAIT_TO_LOAD: 200,    // (ms) Period to wait between checks for language loading
FAIL_TIMEOUT: 120000, // (ms) After this period will stop trying to load languages

These are the meaningful variables, I think they're self explanatory enough, a note of warning though: if some of the languages fail loading you'll have to wait for FAIL_TIMEOUT milliseconds before syntax highlighting gets enabled. Set it too low, though, and you'll get bogus failures.