Notes.

Google Map Shortcode v Google Analytics for WordPress

Today’s quirky discovery: a Google Map that I’d made with the excellent Google Map Shortcode worked in the blog when I was logged in, but when didn’t work when I was logged out.

Investigation of the source code of the page showed that the plugin was trying to create a JSON object, but when logged out, a link had a double-quote:

“Note how everything goes wrong after the href”
1
"info":"<div style='...'><div style='...'><a class='title' href="http://clientswebsite.com/" style='...'>...",

As you can see from the syntax colouring, this breaks the JSON, leading to a syntax error, leading to the map not being created.

It should look like this:

“Note how everything is syntax coloured correctly!”
1
"info":"<div style='...'><div style='...'><a class='title' href='http://clientswebsite.com/' style='...'>...",

Oddly, the Google Maps Shortcode plugin settings page shows a perfectly valid use of single quotes:

Google Maps Shortcode settings page, showing the valid use of single quotes.

So, what’s breaking it? Some forum posts for other Google Maps plugins suggested it might be Google Analytics for Wordpress.

This would make sense: something disabled when a superuser is logged in, and which is rewriting links… which the plugin does, in order to get better data:

Google Analytics for WordPress setting that causes it to rewrite links

Sure enough, disabling that setting makes the problem go away.

So: if your Google Maps shortcode doesn’t work when logged out, suspect a Google Analytics plugin rewriting your links.

Raspberry Pi Workshop

I recently ran a workshop on Raspberry Pis at the Australian National University as part of an Engineering course.

We covered setting up Pis with Raspbian, poking around on their desktop environment and interfacing with hardware. Due to the nature of the course, there’s a strong focus on applications.

The materials are archived here for posterity.

Materials

The presentation itself is available as a PDF and as the LaTeX sources.

The hardware demo board:

circuit diagram for Raspberry Pi demo

Notes:

  • Pin 6 and 25 are both ground pins.
  • Pin 5 has a built-in pull-up, hence the absence of a pull-up resistor.
  • The design assumes that only one LED per set (red/green, red/orange/green) will be on at once. A more flexible/robust design would give each LED its own current-limiting resistor.

We covered two code samples, which are included below. My apologies for the somewhat spartan nature of the code, and lack of comments.

In lieu of comments, some notes:

  • Because the switch is on a pull-up, it’s normally 1, and goes to 0 when pressed.
  • Nothing is cleaned up properly, so you’ll get warnings the second time you run any of the samples.

The first sample is a simple chaser:

chaser.pyDownload
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
import RPi.GPIO as GPIO
import time
GPIO.setmode(GPIO.BOARD)
switch_pin = 5
traffic_red_pin = 26
traffic_yel_pin = 24
traffic_grn_pin = 23
ped_red_pin = 22
ped_grn_pin = 21
GPIO.setup(switch_pin, GPIO.IN)
pins = [traffic_red_pin, traffic_yel_pin, traffic_grn_pin, ped_red_pin, ped_grn_pin]
[GPIO.setup(pin, GPIO.OUT) for pin in pins]
pin = 0
forward = False
while True:
    GPIO.output(pins[pin], GPIO.LOW)

    if not GPIO.input(switch_pin):
        forward = not forward

    if forward:
        pin = pin + 1
        if pin >= len(pins):
            pin = 0
    else:
        pin = pin - 1
        if pin < 0:
            pin = len(pins)-1

    GPIO.output(pins[pin], GPIO.HIGH)
    time.sleep(1)

And one which simulates a pedestrian crossing:

traffic.pyDownload
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
import RPi.GPIO as GPIO
import time
GPIO.setmode(GPIO.BOARD)
switch_pin = 5
traffic_red_pin = 26
traffic_yel_pin = 24
traffic_grn_pin = 23
ped_red_pin = 22
ped_grn_pin = 21
GPIO.setup(switch_pin, GPIO.IN)
pins = [traffic_red_pin, traffic_yel_pin, traffic_grn_pin, ped_red_pin, ped_grn_pin]
[GPIO.setup(pin, GPIO.OUT) for pin in pins]
[GPIO.output(pin, GPIO.LOW) for pin in pins]
mode = 0
forward = False

while True:
    GPIO.output(traffic_grn_pin, GPIO.HIGH)
    GPIO.output(ped_red_pin, GPIO.HIGH)


    while GPIO.input(switch_pin):
        continue

    time.sleep(2)
    GPIO.output(traffic_yel_pin, GPIO.HIGH)
    GPIO.output(traffic_grn_pin, GPIO.LOW)
    time.sleep(2)
    GPIO.output(traffic_yel_pin, GPIO.LOW)
    GPIO.output(traffic_red_pin, GPIO.HIGH)
    time.sleep(1)
    GPIO.output(ped_red_pin, GPIO.LOW)
    GPIO.output(ped_grn_pin, GPIO.HIGH)
    time.sleep(3)
    GPIO.output(ped_grn_pin, GPIO.LOW)
    for i in range(10):
        GPIO.output(ped_red_pin, GPIO.HIGH)
        time.sleep(0.25)
        GPIO.output(ped_red_pin, GPIO.LOW)
        time.sleep(0.25)
    GPIO.output(ped_red_pin, GPIO.HIGH)
    time.sleep(1)
    GPIO.output(traffic_red_pin, GPIO.LOW)
    GPIO.output(traffic_grn_pin, GPIO.HIGH)

I’m happy to answer questions and help out with Raspberry Pi projects: my contact details are in the presentation.

Stopping Trackbacks and Pingbacks on WordPress. In Bulk. Permanently.

Part of a contract I’ve been doing involves stopping pingback and trackback spam on a WordPress site. They’re not using WordPress as a blog but as a CMS, so there’s no need for comments/pings/trackbacks at all.

So I wanted to globally disable pingbacks and trackbacks. If you Google that, you’ll get something like this:

Close all the comments and pings on all published posts and pages.Source (corrected)
1
2
3
4
UPDATE wp_posts SET comment_status='closed' WHERE post_status = 'publish' AND post_type = 'post';
UPDATE wp_posts SET comment_status='closed' WHERE post_status = 'publish' AND post_type = 'page';
UPDATE wp_posts SET ping_status='closed' WHERE post_status = 'publish' AND post_type = 'post';
UPDATE wp_posts SET ping_status='closed' WHERE post_status = 'publish' AND post_type = 'page';

This should work.

However, somehow trackbacks were being reopened: ping_status and comment_status were being set back to open in the database, allowing more spam in. Despite spending half a day mucking around in the internals, I wasn’t able to figure out why, and I couldn’t afford to spend any more time looking.

I was tempted to just modify wp-trackback.php to just break trackbacks, but wanted a solution that would persist past an upgrade. I discovered in poking around that the posts_open and comments_open functions – the functions that check if a post is open for trackbacks/pingbacks/comments – both support filters. (Filters are a WordPress ‘feature’ that allows you to totally re-write the output of a function that supports them.)

So, we can simply use the filters to rewrite every single posts_open call to completely ignore the database value and return false. While we’re at it, we do it to comments too:

A way to force all pings and comments to be closed.
1
2
add_filter('pings_open', '__return_false');
add_filter('comments_open', '__return_false');

Placing this in wp-config.php will make it persistent across upgrades. I’ve put mine at the end of the file. (ISTR reading it had to be after some includes.)

This totally stopped all pings, trackbacks and comments.