GregM

wsperuzzi: If you check the Readme, you’ll find instructions for manually inserting the Share This link in your template, rather than having Share This do it for you automatically. If you do that, and only put the link code in your template where you woud like it to appear (e.g., single.php) and not where you don’t want it (e.g., page.php), you’ll be all set.

And to anyone interested in eliminating the 55K of javascript library overhead caused by Alex’s otherwise excellent plugin…

It’s actually pretty straightforward to do, because the plugin relies on just one substantive capability provided by the prototype.js library: Position.cumulativeOffset, which allows the plugin to position the expanded form in the correct place over the top of your page content. If you nuke that line in share-this.php, set the form.style.left and form.style.top each to 0, change the CSS for akst_form to position:relative from position:absolute, and remove the pesky lines that load the prototype.js library in the first place, you’re almost there. The final 2 steps are just to replace all instances of the $() function with document.getElementById() instead and make sure you’ve manually inserted the form contents right below your form link in your theme (rather than, say, putting the form contents in the footer).

What’s the outcome of all that?

First, the form now appears and disappears from within your page content when you open and close it, rather than appearing over the top of your page content. Second, your visitors don’t have to wait for a 55K library to load in addition to your page content just on the outside chance they might click on the Share This link.

You can see it in action in the blog section of my mental health information site.

I wonder whether Alex would consider adding a simple user-configurable boolean at the start of the code so that those who want the extra 55K overhead can choose to do so, while those who would rather avoid it can switch it off without manually editing the code?

All the best,
Greg

Hi Alex,

I’m puzzled by the URL construction at line 428 of share-this.php 1.4, which seems to rely on a non-prettified URL structure. If I kill the non-prettified URL structure by replacing ?p=postID structure with a get_permalink and ?akst_action=share-this appended, this exceedingly cool plugin still seems to work fine, at least under the limited circumstances where I’ve tried it.

Is it OK to do that, or am I inadvertently going to break something and not realize it til it’s too late?

Thank you Alex!

All the best,
Greg

Hi folks,

I’d like to second the suggestion to open up the post slug to access via XML-RPC.

Many of us prefer client-side environments such as MarsEdit for writing posts, as distinct from web-based environments such as WP’s built-in editor, but without access to the post slug via XML-RPC, it’s still necessary to make a special trip to the web-based editor to alter the slug after every post.

(Yes, I realize I could just write posts in Dreamweaver or GoLive or BBedit, and in fact this is what I always did before trying MarsEdit, but the latter is *much* slicker than writing a post in an XHTML editor and then copying and pasting into the web-based editing environment…)

I don’t know how much work it would take to make this possible, though — any thoughts from Podz or others?

All the best,
Greg

Hi likoma,
I’m still using 10.3.5 until some widely reported troubles with 10.3.6 get ironed out (see macfixit.com, for instance), and my experience is like yours — Safari does not display the Quicktag buttons. Firefox, however, displays them just fine, so if you’re keen to do your writing in the WP window, I’d suggest giving FF a try.
Personally, for anything longer than the briefest of posts, I prefer to write in a fully-fledged editing environment and then copy & paste anyway — but it all depends on how you like to write.
Good luck,
Greg