To solve that issues you must encapsulate your callback into another anonymous function (closure) that returns itself to the callback.

 
var locations = [];
locations.push({address:'hauptplatz 1, 4020 linz, austria', 'otherInfo'=>'info'});
 
for(idx in locations) {
    var location = locations[idx];
    var address = location['address'];
    geocoder.geocode({'address':address}, function(location, idx){
        return(function(results, status){
            if (status == google.maps.GeocoderStatus.OK) {
                var latlng = results[0].geometry.location;
 
                console.log(location);
                console.log(idx);
            }
        });
    }(location, idx));
}

1. Icons, Icons, Icons

Bootstrap includes a fat icon sprite with 120 small icons from glyphicons.com. all have transparent background and are available in black and in white.

2. Inline Labels

Put some highlights in your texts with inline labels.

3. Real Button Porn

Buttons in different colors, with and without dropdown and in groups or lonely.

… and what is your favorite feature from twitter bootstrap?

createDate

the createDate of a row is a very nice info that can be used for quick statistics, if your boss wants to know how many users on one day registered you can simple select it via SQL and group by day. you can also modify rows based on this date like: delete all users created before year 2000 or something like this … and you can use it for forensic research: “is it really possible that such a new user already wrote one million comments?”

active, inactive or deleted

i use often a flag like active to mark a row as “not deleted”, you can also turn it to the opposite, important is only that you don’t delete rows in your table … better you mark it as deleted and so you can use it still for statistics or reactivate it some day. if you don’t delete your rows every link to other tables will remain intact.

hidden or visible

it’s almost like active/inactive but a bit different, a hidden row can be active but i don’t want to show it to a frontend user, for example test records can be hidden. in your business logic you can treat a hidden row as normal but in the end don’t show it to the frontend user.

status

is the multi-talent of every database table, you will need it always even if you don’t know it now, in some weeks/month/years you will be so thankfull that you have it. a status col can save you many other cols like active or hidden. this col can be a set or a tiny integer field. the set is better style, the integer is better for extending status types … if you use integers then use constants in your source code or comment the int-values somewhere you easy can find it … i write it in the mysql col description. because i use int as type i usually take 0 as an “unknown” or “new” status, if a status is defined then it gets a positive or negative value … for example 1 = active, -1 inactive or 1 visible and -1 invisible.

changeDate or lastModified

another important date field: as the createDate you can use it for forensics (example: if a user change a password today and wrote that he can’t login since yesterday then something is strange) and statistics (example: users with status:inactive and changeDate today are all users that deactivated their accounts today) but you can also set the lastModified http header from it (google loves it) and maybe you can use it for caching or clean up caches.

id

surprise, surprise … really every table should have a primary key for simpler editing/deleting and fast access.

description

it’s not always necessary to have a description for a row, but really often. the description field is a varchar or text field for an internal notice, it won’t be shown to a frontend user. there are so many scenarios where you can need it … admins can write why the record is like it is, or it can hold a brief history of changes, or just who has changed the row. sometimes it’s abused for settings ( example: a menu-entry with description dns=1 … it means DoNotShow=1 don’t do that please )

… thats my silver bullets for database design … what do you think!

Features:
- Set watermarks for galleries
- Watermark button on gallery screen
- Set position of watermark in source code
- Pictures gets the watermark only once also if you click again
- Inserts watermarks only in the big version of the file (not in thumbnails)
- Watermarks are not removable from the images

Install and Requirements:
- copy the source code to the functions.php
- Image Magick (composite command) is required

 
add_filter('media_upload_form_url', 'bohuco_upload_gallery');
 
if(isset($_GET['tab']) && $_GET['tab'] == 'gallery') {
	if ($_POST['attachments']) {
		$uploadDir = wp_upload_dir();
		foreach($_POST['attachments'] as $id => $a) {
			$a = wp_get_attachment_metadata($id, true); // 'full'
			if($a['image_meta']['copyright'] != '_WATERMARK_') {
				ffs_image_modify($uploadDir['basedir'].'/'.$a['file']);
				$a['image_meta']['copyright'] = '_WATERMARK_';
				wp_update_attachment_metadata($id, $a);
			}
		}
	}
}
 
/**
 * adds the watermark button to the gallery dialog
 */
function bohuco_upload_gallery($var) {
	if(isset($_REQUEST['watermark']) && ! empty($_REQUEST['watermark'])) {
		$html = "<script type=\"text/javascript\">jQuery(function(){ jQuery('<tr><td colspan=2>Watermark added!</td></tr>').appendTo('#gallery-settings table'); }); </script>";	
	} else {
		$html = "<script type=\"text/javascript\">jQuery(function(){ jQuery('<tr><td><input type=\"submit\" class=\"button savebutton\" name=\"watermark\" id=\"save-all\" value=\"Insert watermark\"></td></tr>').appendTo('#gallery-settings table'); }); </script>";	
	}
	echo $html;	
	return $var;
}
 
/**
 * modify an image
 */
function bohuco_image_modify($file) {
	// watermark image ... use png or gif with alpha
	$watermark = dirname(__FILE__).'/images/watermark.png';
 
	// imagemagick command ... set gravity to NorthWest, North, NorthEast, West, Center, East, SouthWest, South, SouthEast
	$command = sprintf("composite -gravity Center %s %s %s", $watermark, $file, $file);
 
	exec($command, $return, $code);
	return $code;
}

Framebreaker – X-Frame-Options

Mit dem Header X-Frame-Options:DENY wird angezeigt das die Seite nicht in einem iFrame/Frame eingebunden werden darf. Alternativ geht auch die Einstellung: SAMEORIGIN damit zumindest Seiten von der selben Domain die Seite framen dürfen.

Nicht Tracken – DNT

Der DNT (Do Not Track)-Header wird vom Firefox als Anfrage-Header mitgeschickt wenn der Benutzer das konfiguriert hat. Er soll anzeigen das man den User nicht für Werbezwecke verfolgen soll. Laut Blog Artikel sind damit die “Online Behavioral Ads” bzw. Remarketing gemeint.

User Agent kürzer

Der Firefox User Agent Header wurde verkürzt und verrät jetzt weniger. Der UA für Firefox 4 sieht damit zum Beispiel so aus:

Mozilla/5.0 (Windows NT x.y; rv:2.0.1) Gecko/20100101 Firefox/4.0.1

SSL aber fix – Strict-Transport-Security

Der Strict-Transport-Security Header zeigt an das die Seite nur über SSL aufrufbar ist. Dieser Header wird vom Server geschickt und dann im Browser zwischengespeichert. Nach dem ersten Aufruf weiß der Browser also dann immer das die Seite nur verschlüsselt angezeigt werden kann. Man kann den Header auf Subdomains ausweiten und mit einem Timeout versehen:

Strict-Transport-Security: max-age:expireTime [; includeSubdomains]

“PHP Fog – Reliable Cloud Platform” ist erst vor kurzem gestartet und musste schon nach wenigen Tagen wieder offline gehen. Das vielversprechende Unternehmen bietet Platform as a Service (PaaS) für PHP an. Mittels weniger Klicks kann man neue Cloud-Applikationen erstellen und sogar mit beliebten Open Source Programmen befüllen. So ist das neue WordPress-Blog in wenigen Minuten online und kann beliebig angepasst und erweitert werden.

In der Theorie hört sich das besser an, als es in der Praxis funktioniert hat. Denn nur wenn die ganze Plattform gut durchdacht und ausfallsicher ist funktionieren auch die einzelnen Applikationen und da haperts bei PHPFog anscheinend noch gewaltig.

Chronik:
Letzten Samstag kam das erste Mail das meine (Test-)Applikation nicht mehr online ist weil die Plattform von Hackern angegriffen wurde:

“On Saturday March 15th at 11pm, the main PHP Fog site was compromised by a group of hackers. I want to let you know how sorry I am, but you do not have to worry.”

Stunden später dann das nächste Status-Update zum Ausfall:

“I am very sorry for the inconvenience. Our team has been working non-stop for over 21 hours now and have reached the point of exhaustion. We are performing a comprehensive audit and security upgrade to prevent anything like this from happening again. This upgrade unfortunately is taking longer than we expected.”

Erst vier Tage späte konnten alle Seiten wieder online geschaltet werden, auch wenn sich die Plattform-Betreiber anscheinend nicht ganz sicher sind:

“Your PHP Fog sites should be running again”

Meine Test-Seite ist immer noch nicht online, ist aber auch nicht so wichtig, aber was wäre wenn ich eine richtig große und bekannte Seite/Domain zu PHPFog transferiert hätte und jetzt vier Tage offline gewesen wäre? Was würden meine Kunden dazu sagen?

Was war passiert?

Ein paar “Teenager” haben wohl eine Sicherheitslücke auf einem alten Server entdeckt der als Ausfallsicherung fungiert hat.

Lucas Carlson beschreibt den Angriff im Firmenblog, inklusive der Gegenmaßnahmen die solche Angriffe in Zukunft verhindern sollen.

Trotzdem: Keine besonders gute Werbung für die Cloud oder PaaS. Was vor 15 Jahren die 1-Mann-Hosting-Buden waren, sind jetzt anscheinend die 20-Mann-Cloud-Buden? Alles schön billig, aber dafür auch schön unsicher.

Angeblich waren ziemlich viele unglückliche Zufälle und “Bad Timings” Schuld an der ganzen Misere. Genauer betrachtet haben sie ihren Legacy-Code nicht entfernt, waren nachlässig mit den Passwörtern und haben Fehler in der Architektur gemacht.

Also: Immer schön Vorsichtig bei der Auswahl des Hostings sein und nicht einfach auf den billigsten Anbieter wechseln, oder in die Cloud, nur weil es gerade Hip ist.

We need the HTML for the language-chooser and a short javascript …

 
<script> 
 
	$(function(){
		$('#languages a').click(function(evt){
			$('#content').translate($(this).attr('rel'));
			$('#languages a').removeClass('active');
			$(this).addClass('active');
		});
	});
 
</script>
 
<div id="languages">
	<a rel="de" class="active" href="#">Deutsch</a>
	| <a rel="en" href="#">English</a>
	| <a rel="es" href="#">Español</a>
	| <a rel="fr" href="#">Française</a>
</div>

Das Bloggergate in Deutschland hat zumindest in einschlägigen Kreisen für etwas Wirbel gesorgt. Da ging es um die intergenia AG die auch das bekannte deutsche Blog “Basic Thinking” betreibt. Aber das neue, amerikanische Bloggergate das die New York Times jetzt aufgedeckt hat spielt in einer anderen Liga.

JC Penney ist ein großer amerikanischer Retailer und Online Store der in den letzten Monaten mit ausgezeichneten Suchergebnissen glänzte. Für viele generische Produkt-Kategorien wie: “home decor”, “skinny jeans”, “tablecloth” … wurden Seiten von jcpenney.com auf Nummer Eins gezeigt.

Das ging solange gut bis sich jemand gewundert hat und mal im opensiteexplorer die eingehenden Links nachgeprüft hat. Dabei ist dann schnell aufgefallen das die meisten Links von irgendwelchen Seiten kommen die absolut gar nichts mit Kleidung oder Haushalt zu tun haben.

Seiten wie nuclear.engineeringaddict.com oder casinofokus.com linkten im Footer mit den besagten Begriffen auf jcpenney.com. Das J.C. Penney nicht selber alle Blogger angeschrieben hat liegt wohl auf der Hand es wahr anscheinend die SEO Agentur SearchDex die über das Link Netzwerk TNX die Links gekauft hat.

Bei TNX bekommt man pro Link sogenannte TNX Points die man dann wieder gegen eingehende Links eintauschen kann. Dabei wird einfach mittels Perl oder PHP Script eine beliebige Anzahl von Linkplätzen auf der Seite markiert die TNX dann befüllen kann.

Mittlerweile wurde jcpenney.com schon abgestraft und erscheint für die angesprochenen Begriffe nicht mehr auf der ersten Seite. Google ist aber nur durch den Hinweis der NYT draufgekommen und die Masche hat immerhin min. vier Monate funktioniert.

tnx.net dürfte ab jetzt also tot sein … aber fraglich ist schon warum Google das nicht früher gecheckt hat.

via gizmodo, new york times

“Signierte Requests”, “Request- und Access-Token” … alles nicht so schlimm wie es sich anhört. Die Zend_Oauth_Consumer Klasse von Zend Framework nimmt einem die meiste Arbeit ab. Am Beispiel von Twitter zeig ich mal schnell wie das geht.

Allgemein
Der grundsätzliche Ablauf ist folgender: Als erstes bei der API einen Request-Token anfordern, mit diesem Token dann den Benutzer auf die Twitter-Seite umleiten (Redirect) und wenn der Benutzer auf “Erlauben” klickt wird man zurück auf die eigene Seite umgeleitet und bekommt einen Access-Token.

Für den ganzen Ablauf muß man sich vorher von Twitter einen consumerKey und consumerSecret abholen, dazu muß die eigene Anwendung, die auf die Twitter API zugreifen will, registriert werden. Das kann man unter folgender URL machen: http://dev.twitter.com/apps/new

 
$config= array(
	'callbackUrl' => 'http://bohuco.net/labs/twitter-backup',
	'siteUrl' => 'http://twitter.com/oauth',
	'consumerKey' => 'ueQgVFLypAzN0vkbiZiyw',
	'consumerSecret' => '9SB9W8J66lPsKyu766bzGpoPN21q0tjJh6JV1Rp8'
);

Request Token anfordern
Der Request Token dient dazu die nachfolgende Anfrage zu signieren und gilt immer nur für einen Request. Man braucht ihn also für den nachfolgenden Redirect auf die Twitter-Authorize Seite. Den Request Token muß man aufheben weil man damit die Antwort von Twitter wieder entschlüsseln muß darum speichern wir ihn in der Session.

	$consumer = new Zend_Oauth_Consumer($config);
	$token = $consumer->getRequestToken();
	$_SESSION['TWITTER_REQUEST_TOKEN'] = serialize($token);

Wenn man den Request Token in der Session hinterlegt hat kann man den Benutzer auf die Twitter Seite umleiten und hoffen das er mit einer positiven Antwort zurückkommt …

	$consumer->redirect();

Falls der Benutzer dann wirklich zurückkommt wird mittels Request-Token (aus der Session) und der Antwort von Twitter (die in $_GET steht) der Access-Token erzeugt. Den Access-Token kann man entweder in der Session oder in der Datenbank speichern, er läuft nicht ab und gilt solange bis der Benutzer diese Berechtigung bei Twitter wieder aufhebt.

Den Request-Token kann man vergessen den braucht man jetzt nicht mehr.

	$consumer = new Zend_Oauth_Consumer($config);
	$_SESSION['TWITTER_ACCESS_TOKEN'] = serialize($consumer->getAccessToken($_GET, unserialize($_SESSION['TWITTER_REQUEST_TOKEN'])));
	$_SESSION['TWITTER_REQUEST_TOKEN'] = null;

Der gesamte Quelltext würde dann ca. so aussehen …

 
$config = array(
	'callbackUrl' => 'http://bohuco.net/labs/twitter-backup',
	'siteUrl' => 'http://twitter.com/oauth',
	'consumerKey' => 'ueQgVFLypAzN0vkbiZiyw',
	'consumerSecret' => '9SB9W8J66lPsKyu766bzGpoPN21q0tjJh6JV1Rp8'
);
 
// get request token and redirect user to twitter authorize page
if (! isset($_SESSION['TWITTER_ACCESS_TOKEN'])) {
	$consumer = new Zend_Oauth_Consumer($config);
	$token = $consumer->getRequestToken();
	$_SESSION['TWITTER_REQUEST_TOKEN'] = serialize($token);
	$consumer->redirect();
}
 
// user come back from twitter
if (! empty($_GET) && isset($_SESSION['TWITTER_REQUEST_TOKEN'])) {
	$consumer = new Zend_Oauth_Consumer($config);
	$_SESSION['TWITTER_ACCESS_TOKEN'] = serialize($consumer->getAccessToken($_GET, unserialize($_SESSION['TWITTER_REQUEST_TOKEN'])));
	$_SESSION['TWITTER_REQUEST_TOKEN'] = null;
}
 
// user has granted access ... now we can use the api
if (isset($_SESSION['TWITTER_ACCESS_TOKEN'])) {
 
	$token = unserialize($_SESSION['TWITTER_ACCESS_TOKEN']);
	$userName = $token->screen_name;
 
	$twitter = new Zend_Service_Twitter(array(
		'username' => $userName,
		'accessToken' => $token
	));
 
	$status = $twitter->account->rateLimitStatus();
	// ...
}

Damit man es besser versteht hab ich das in einer Grafik festgehalten …