Tag Archive: JavaScript

Spam is website publishers #1 concern, we wanna share our and our visitors' emails to those who should have access to them, but don't want spam harvesters stealing them and sending garbage to us. A lot of techniques had been developed to hide our emails from these delinquents, while having them shown to real people.

And together with spam harvesting, on 15 June 2009, Matt Cutts, a well known software engineer of Google, announced that Google Bot will no longer ignore nofollowed links for PageRank (http://www NULL.mattcutts NULL.com/blog/pagerank-sculpting/), and now we lose PR/link juice for every link we add to our pages, even if we use rel="nofollow" on them. So, now we must hide links from Search Engines too!

I've been searching for an ultimate obfuscation solution for both emails and URLs, that would be user-friendly for me the content publisher, and for my visitors. I've seen a lot of solutions, some that inspired me, but none that would fit my needs. It was time to start coding

Hikari Tools Framework isn't a plugin with features for the end user. It's a development framework with tools to be used by other plugins, so that they don't need to duplicate the same code over and over again.

It deeply decreases plugins development time, specially in building options pages. For that, instead of building the whole HTML for each plugin, we can just prepare an array and it's used to build the whole page.

Another great feature this framework offers is options detection and reset. With the use of another simple array, in the bottom of options page it prints a table showing to plugin's users all kinds of options the plugins creates, being it wp_options, comment meta, post meta, and even network-wide options and user specific options (usermeta).

Every kind of data your plugin stores in database is shown in a clear way, with its key so that users can easly search for them in database. But they don't need to, because together with each option it informs if there's any data of that type stored, and provides user -friendly command to reset them all, totally cleaning the user's database from any data created by the plugin. Very easy and practical to use, and instantly available to any plugin that consumes Hikari Tools Framework!

Wordpress 3.0 comes with a new filter that lets us customize what is used for each permalink structure tag, other than Wordpress default.

One of these permalink structure tags is %category%. By default, Wordpress always use the category with lowest ID, making %category% impractical for SEO optimization.

Hikari Category Permalink allows post authors to choose among each post's categories, which of them is used in that post permalink, giving much more flexibility and power to permalinks.

This plugin is a fork of Dmytro Shteflyuk (http://kpumuk NULL.info)'s sCategory Permalink (http://kpumuk NULL.info/projects/wordpress-plugins/scategory-permalink/) plugin. It has all original features and is compatible with original options, while being more stable and simple, and also fixes 2 recurring bugs.

I've been developing Wordpress plugins for a few months, and I always felt challenging to know if those hooks I was using were being used by other plugins as well, and which were coming before and after my function.

Wordpress hooks are actions and filters. They are known by theme designers as those "things" that come in do_action("action_tag"); and $content= apply_filters("filter_tag",$content);. Plugin developers know them better, we love to hook actions and filters as add_action("action_tag","prefix_function"); and add_filter("filter_tag","prefix_function");.

I just wanted something that, in any page I wanted, would show me a list of all hooks, everything hooked to each of them, and the priority order they were called.

Of course that couldn't be something like a static model designed by (my) hand, it should be something automatic, dynamic, related to each page. Something real, that showed what really happened during that particupar page load.

With some research I found codes that did that, and much more. I merged these codes together, improved them, and Hikari Hooks Troubleshooter was born

Introduction

Wordpress has a "bug" regarding marking up JavaScript inside posts and pages, and Hikari Email & URL Obfuscator unfortunately is affected by it. This "bug" breaks XHTML validation, and something has to be done to surpass it and have a properly valid XHTML code, while the "bug" is not solved.

Most people don't really bother with XHTML validation. Indeed, I'd say that 99,98% of all webpages on the Web today have their DOCTYPE setted automatically (be it for a site builder or a CMS) without its author even knowing about it.

Just browse sites over the Web, even from big companies, and you'll see how rare it is tp find a HTML document 100% valid.

In this article I'm gonna talk a bit about validation in general, about XHTML validation when JavaScript is in place, explain the problems I've faced with my Wordpress plugin Hikari Email & URL Obfuscator when I tried to insert JavaScript inside posts, and what I did to solve it. That's a lot to talk, so use the following Table of Contents to go directly to your concerning subject, or read the whole article with no hurry

I've been developing Wordpress plugins for months, and I always felt challenging to know if those hooks I was using were being used by other plugins as well, and which were coming before and after my function.

Wordpress hooks are actions and filters. They are known by theme designers as those "things" that come in do_action("action_tag"); and $content= apply_filters("filter_tag",$content);. Plugin developers know them better, we love to hook actions and filters as add_action("action_tag","prefix_function"); and add_filter("filter_tag","prefix_function");.

I just wanted something that, in any page I wish, would show me a list of all hooks, everything hooked to each of them, and the priority order they were called.

Of course that couldn't be something like a static model designed by (my) hand, it should be something automatic, dynamic, related to each page. Something real, that showed what really happened during that particupar page load.

With some research I found codes that did that, and much more. I merged these codes together, improved them, and Hikari Hooks Troubleshooter was born

Gravatar is a nice service, it allows us, as users, to define avatars related to our emails, and then those avatars are used everywhere we comment and participate, automatically.

But not everybody know or bother with Gravatars, and when we have a site we end up with a bunch of comments with the same default avatar, for every commenter that didn't register on Gravatar, or in anonymous comments.

Hikari Unicornified Gravatars lets us "unicornify" these avatars, providing some more colors to our beloved sites

Donate

If you enjoy any of my plugins, please consider a donation. You can do it through Paypal:

There are also several ways you can show your appreciation:

blogging about it

linking it from your site (without using rel=nofollow, and of course not obfuscating the link )

Many people when start developing plugins and themes to Wordpress don't notice the consequences of writing messy codes until it is too late.

I decided to decicate a whole post to this prefix matter because I know I will come back to it always when possible, and it will be easier to have a post to link instead of repeating myself.

Using a prefix means that, for each plugin or theme we create, we choose a small string that describes this piece of code, and in every function/class, and even hook tags, we add this string before its name.

It may seem boring to those people that still don't understand why this is important, but I'll explain.