Star Rating: Behind the Scenes

Without any doubt, GD Star Rating is the most complex plugin made for WordPress to date. And when you first look at the interface and everything else, you will be stunned and perplexed on how to use the beast. And it will take you a while to understand how simple is to use the plugin…

… and I know that many of you will disagree with that, so I decided to go through the mechanics of the plugin to show how things are actually working. You need to understand that there are things that are not done the best way, and that upcoming GD Star Rating 2.0 will change many elements, but GD Star Rating development started in the may of 2008, and new versions were released 3-4 times a month, with new features added, things improved and to satisfy the users that demanded more and more, plugin was growing to a beast that it’s right now. And GDSR 2.0 will be much more powerful than current one, and will be more universal to use beyond posts and comments.

Do you need to change your theme?

In most cases you don’t need to change anything. Basic idea plugin follows is that only bare minimum of changes to the theme are required. For displaying rating blocks and widget no changes are needed. For displaying rating block you need to change the theme only if the auto insert location is not what you want (plugin uses post or comment content to add rating block). Some more complex integration might require that you add few function calls in the theme, but nothing big. The only thing that requires direct integration is expanding comment form with rating block so that rating is submitted with the form, and that is required due to limitations in WordPress, not in plugin.

Displaying rating block

There are 3 ways to display rating block (comments, post, page, multis or standard, or thumbs, it’s all the same). Auto insert is main method, and shortcodes and functions can be used. But, all three methods perform exactly the same. First thing that plugin does is to check where the request is came from. Request is handled differently for regular browser based requests and search BOT’s. Also, IP is checked against the IP filter. Next step is to check if the voting is allowed: time restrictions, cookie, previously logged vote. And after that rating block is set to active or inactive.

Now plugin has everything it needs, and it’s time for rendering. If block is auto inserted, plugin gets the template set on the settings panel. If it’s shortcode or function based, plugin takes template id from the call. If the id is set to zero or is not provided (it’s zero), plugin finds default template for the rendering. And uses this template. Now, template and all the prepared data is sent to rendering function that processes the template and replaces the template tags with the data. As a result, function now has rendered HTML of the rating block. And this is displayed (if auto insert is used or function is set to echo it), or returned as a string.

Displaying results or widgets

This is based first and foremost on the settings provided. These settings can be set in the widgets panel, or as array of settings in the function call or shortcode. These settings are processed against default values. But, before these settings are used to retrieve the data, we need template.

Template is specified with every code, or can be set to zero (or omitted). If is set to zero, plugin finds default template for the type of rendering required, and this is again done for all types of rendering and all kinds of templates. But, for results, template is used to get the data also. If the template uses some specific tags, these tags can influence if the plugin needs to get some data or not. For instance, if widget template has trend tags in it, plugin will retrieve trends data.

Now we have all settings, and they are used so that plugin can get the data from the database. And once the data is ready, tags in the template are replaced with it, and returned as HTML.

Cache

Plugin caches everything: posts and comments data, and templates. Data is cached only if plugin decides that it’s needed, and that’s again based on the page that is being rendered. Templates are cached when they are first requested. If rendering requires template by the ID 1, it will be retrieved and cached. If during the page rendering this template is required again, it will be used from cache.

Is it really so complicated?

Well, when you read this you see that there is a lot going on in the background. But nothing of that requires anything from you. Biggest issue is using the templates. But that also is simple if you are using default templates, because in all instances you can forget about it. If you use own templates, than you always need to provide accurate template ID for the call, or if you don’t, default template will be used.

For 99% of all uses, everything is already set, and plugin is very easy to use, with no changes to the theme required. But, if you need to change rendering and default templates are not enough, you must make your own templates. Template is pure HTML (with custom %TAGS%), and uses CSS for styling. But all that is done through control panel, again, no changes to the theme are required if you are changing templates.

Comments

Leave a Reply