Get rid of WP-Admin redirects

Posted July 26th, 2012 by guidone with No Comments

Have you ever tried to work on your local code base of WordPress using a shared database (for example the database on staging/development server) with the rest of the team?
Normally it’s not possible since WordPress stores the URL of the blog in the database and immediately redirects if the current host name doesn’t match the stored value.

Using a centralized version of the database might be useful, in particular if more developers are working on the same blog and they don’t want to replicate locally all the settings of the database in staging/dev.

Here is a plugin for that:

<?php
/*
Plugin Name: Disable Canonical/WP-Admin URL Redirection
Description: Disables the "Canonical URL Redirect" and "WP-Admin Redirectr" features of WordPress .
Version: 1.0
Author: Guido Bellomo
Author URI: http://javascript-jedi.com/
*/

function fake_siteurl() {
   return 'http://'.$_SERVER['HTTP_HOST'];
   }
add_filter('pre_option_siteurl', 'fake_siteurl');
add_filter('pre_option_home', 'fake_siteurl');
?>

Just copy and paste this in a file inside the plugin directory (for example /wp-content/plugins/disable-redirect.php).

P.S. There are similar plug that works on the redirect_canonical filter, which works for the home page, but it doesn’t for the administration panel. This plugin cheats WordPress faking the option “siteurl” and “home”.

Works nice for blogs hosted in the root directory of the domain, for blogs hosted in subdirectory additional PHP might be required in the fake_siteurl() function.
Pay attention on disable the plugin in a production environment since it could compromise the blog security.

CORS, get over it!

Posted July 25th, 2012 by guidone with No Comments

We’ve been growing up with the dogma: “AJAX cannot make cross site calls”.
Then CORS happened: with some configuration on HTTP server headers it’s possibile to make cross site AJAX calls, it’s widely adopted by modern browsers but it was not love at first sight: I’m not particulary happy with people calling my APIs from a different domain and when I have to, JSONP is just fine.

Eventually came the day when I cannot pretend CORS doesn’t exist.
I’m using Heroku for my projects and I usually keep all my static resources on Amazon S3 or Google Cloud Storage. During the last deploy I noticed that Firefox stopped loading a font with CSS @font-face rule on productions servers. It took me hours to realize that was a security restriction: Firefox will not load any font file from a different domain unless CORS is enabled.

Unfortunately Amazon S3 doesn’t support CORS (and it won’t support any sooner, there’s a two years old thread about this topic in the support forum, still unresolved), Google Cloud Storage does and it’s quite easy:

Install the tool gsutils and create this file cors.xml:

<?xml version="1.0" encoding="UTF-8"?>
<CorsConfig>
   <Cors>
      <Origins>
         <Origin>http://mydomain</Origin>
      </Origins>
      <Methods>
         <Method>GET</Method>
         <Method>HEAD</Method>
      </Methods>
      <ResponseHeaders>
         <ResponseHeader>x-goog-meta-foo1</ResponseHeader>
      </ResponseHeaders>
      <MaxAgeSec>1800</MaxAgeSec>
   </Cors>
</CorsConfig>

And then cast the command

gsutil setcors cors.xml gs://my_bucket

It will enable CORS for the whole bucket (be sure to match exactly the domain in the Origin tag, with protocol and host port).

Update: Amazon S3 started supporting CORS!

Event broadcast in jQuery

Posted June 27th, 2012 by guidone with 4 Comments

Eventbroadcast it’s a small library to improve the functionality of bind()/trigger() methods.
This plugin extends jQuery with the method $.trigger(‘‘) which calls the event named <event_name> on all elements previously registered to the event through .bind() and .one().

The main problem with the classic jQuery $(‘‘).trigger() method is that must be used on the element that receives the events, leaving Publish/Subscribe pattern uncomplete: we need to programmatically know the elements to cast the event to.

With the Publish/Subscribe pattern it’s easy to decouple the code in charge to create the event from the code that receives it: the event emitter doesn’t know (and doesn’t care), at runtime, who is listening to the event (speaking with the words of academics, it’s not aware of the topology of the elements).
The more the code is decoupled, the more is maintanable.

Continue Reading

  • Categories

  • Tags

  • Enter your email address to subscribe to this blog and receive notifications of new posts by email.

    Join 2 other subscribers

  • Twitter

    Flickr Stream