Hier mal ein Beispiel, wie sowas aussieht:

HAI!
I'M IN UR `table`
SELECTIN UR `column` AZ `label`
I CAN HAZ `column` LIEK `value`
GIMMEH 5
MAKES ORDER `column` GOAS DOWN
KTHNXBYE

So, Nerds. Jetzt bitte noch einen Parser bauen. Kthxbye!

Der @moeffju hat’s entdeckt.

Keine relevanten Artikel.

Keine relevanten Artikel.

MAMP und Zeugs

MAMP ist ja ein richtig nettes kleines Spielzeug. Ein kompletter Webserver, out-of-the-box, zum Spielen und Spaß haben. Was aber die Jungs (und Mädels?) von living-e irgendwie völlig verpeilt haben, sind die marginalen Ressource, die sie MAMP bzw. dem entsprechenden Server zukommen lassen. Ein mageres, 8 MB „großes“ Memory-Limit gesteht die originale php.ini zu. Viel zu wenig für Brocken wie TYPO3. Die 4.2er Version hätte dann doch schon gerne 64 MB zum Kauen (32 MB gelten als empfohlen, naja …).

Leider scheint es mit MAMP aber nicht so richtig weiterzugehen. Das letzte Update gabs irgendwann im August 2007, ist schon eine Weile her. Oder es gibt schlicht nichts zu verbessern? Keine Ahnung, wäre jedenfalls schade, wenn diese nette und unkomplizierte Lösung so allmählich dahinsiecht.

Und wie komm ich da jetzt drauf?

Ganz einfach: Versucht mal, TYPO3 4.2.2 lokal bei 8 MB Limit zu installieren. Ihr seht ganz genau: Nix! Das Installations-Tool wird gar nicht erst gestartet und man sitzt vor einem weißen Bildschirm.

Da man irgendwann den Wald vor lauter Bäumen nicht mehr sieht und im Grunde recht logisch erscheinende Fakten übersieht, braucht es halt etwas Recherche. Aber dann macht es schlicht *klick*: Man muss lediglich das Memory-Limit auf 64 MB setzen, fertig. Manche Probleme lösen sich ja dermaßen rapide in Rauch auch, dass man sich fragt, wieso man dafür eigentlich graue Zellen braucht … Egal.

Die php.ini findet sich unter Programme/MAMP/conf/php5/. Der Rest sollte klar sein. Server neu starten und dann sollte die Installation laufen.

MAMP und virtuelle Maschinen

Wer jetzt denkt, er kann nun nicht mehr die Browservielfalt einer Online-Variante nutzen, der irrt. Es ist ein leichtes, beispielsweise unter VMWare Fusion seine Seiten zu testen. Hier muss als URL statt des üblichen http://localhost:8888/ die spezifische IP des Hosts, als von OS X, eingetragen werden, beispielsweise http://192.168.1.111:8888/ Hier bieten sich natürlich feste IPs an.

Keine relevanten Artikel.

Fakt ist, dass bspw. die TYPO3-Extension „LumoNet Google Maps“ (lumogooglemaps) mit diesen (alten) Variablen arbeitet und so den Kartentyp versucht zu bestimmen. Was seit neuestem allerdings nicht mehr funktionieren dürfte – zumindest bei einer meiner Kundenseiten. Dies äußert sich in dem Punkt, dass die Karte zwar generiert und angezeigt wird, aber keine Marker mehr erscheinen, was auf die nicht vorhandene Variable G_MAP_TYPE zurückzuführen war.

Um die Marker wieder ranzuholen, muss entsprechend in der API-Schnittstelle ein kurzer und schmerzloser Eingriff vorgenommen werden. Es ist zwar ein Rumgehacke in einer Core-Datei, aber es ist schlicht die schnellste Lösung, da ich nicht auf ein Update warten kann (man erkläre das mal dem Kunden …).

Folgende Zeilen der GoogleMapAPI.class.php müssen angepasst werden:

• Z. 122 – legt den Standardwert fest; G_MAP_TYPE » G_NORMAL_MAP
• ab Z. 397 – in der Funktion setMapType müssen alle Variablen angepasst werden:
  • G_HYBRID_TYPE » G_HYBRID_MAP
  • G_SATELLITE_TYPE » G_SATELLITE_MAP
  • G_MAP_TYPE » G_NORMAL_MAP

Eine komplette Entfernung/Auskommentierung der Zeile 969 würde das Variablenproblem lösen, führt aber dazu, dass man nur noch den Standardwert aufgedrückt bekommt – wer damit leben kann, kann’s auch so machen.

Haftungsgedöns: Wer in Core-Dateien rumwurschtelt, macht das auf eigene Gefahr. Der hier beschriebene Weg hat bei mir funktioniert und ich gehe mal davon aus, dass er es bei Euch auch tut. Wenn Ihr aber was kaputt macht, ist das Euer Bier, m’kay?

Nachtrag: IE6

Wer hätte etwas anderes erwartet … Durch die Änderungen stellt der IE6 als einziger (noch benutzter) Browser den Lumo-Marker nicht da. Wenn man keine speziellen eigenständigen Marker nutzt, kann man durch die Angabe …

plugin {
  tx_lumogooglemaps_pi1 {
    marker.icon =
  }
}

… im TypoScript generell die Standardmarker von Google nutzen. Wer ganz spezielle Marker nutzt und auf die Darstellung im IE6 verzichten kann, der kann eine globale Variable definieren und nur den IE mit der ollen Google-Krücke „verzieren“:

[browser = msie6]
plugin.tx_lumogooglemaps_pi1.marker.icon =
[global]

Vielleicht kann man auch am Bildpfad arbeiten, aber das war mir persönlich jetzt zu aufwändig. Die Arbeit bezahlt ja wieder keiner …

Keine relevanten Artikel.

Eine sehr interessante Sache, wie ich finde. Es ist mir schon mehrmals passiert, dass ich die Funktionalität des aktuellen Statusgemehres verwechselt und zwar einen zukünftigen Artikel abspeichert habe, aber dann am „Ereignistag“ vergeblich auf den Artikel gewartet hab … Ich hoffe mal, dass mit der überarbeiteten Box mehr Klarheit da reinkommt.

Die nächsten Tage werde ich mich persönlich auch ans Testen von Wordpress 2.7 begeben. Frank hat ja schon reichlich von geschwärmt.

Keine relevanten Artikel.

I Took The Survey 2008

… for people who make websites!

Alle Webentwickler sollten sich ruhig an dieser anonymen Umfrage von A List Apart beteiligen. Es ist die größte Umfrage dieser Art, die speziell an Webentwickler (und alle „Berufsformen“, die in dieser Branche tätig sind), gerichtet. Wer durch ist, darf sich dann auch diesen netten Banner auf die Seite packen!

zur Umfrage »

Keine relevanten Artikel.

Firefox-Logo

Der Firefox 3 ist so eingestellt, dass nun auch Popups mit einer Adresszeile angezeigt werden. Im ersten Moment scheint das eine nette Eigenschaft zu sein, allerdings stellt sich rasch die Frage: Wozu, bitte? Surft etwa jemand in einem kleinen Fenster weiter?

Natürlich nicht. Eher geht es darum, dass man die aktuelle URL der (zumeist Werbe-)Popups ermitteln kann. Aber der Nutzen dahinter ist wohl eher als gering einzuschätzen. JE beispielsweise interessiert die nicht und sie stört ihn schlicht und ergreifend.

Hier nun wieder ein kleiner Workaround, wie man die Adresszeile ausblenden kann.

about:config – ja, ich pass schon auf

1. Gebt in die Adresszeile about:config ein und bestätigt die folgende Seite mit „ja“.
2. Filtert die Ansicht dann nach nach dom (oder direkt nach der Zeile aus 3.).
3. Sucht etwas unten die Zeile dom.disable_window_open_feature.location.
4. Diese steht auf true; per Doppelklick auf false setzen (gefixt; danke, Aro)
5. Fertig, die Adresszeile wird innerhalb eines Popups nicht mehr angezeigt.

Auch hier gilt wieder: In der Konfiguration arbeiten geschieht auf eigene Gefahr!

Nachtrag

Ein generiertes JavaScript-Popup, was das Setting location=no enthält, zeigt trotzdem die Adresszeile an. Die Adresszeile hat allerdings keinen negativen Einfluss auf die dargestellte Größe des Viewports. Angegebene 400 Pixel sind auch 400 Pixel (Beispiel; und was andere Browser machen ist wieder eine andere Geschichte).

Ich habe dazu eine kleine Testseite zusammengebastelt (englisch).

Kurze Beschreibung

Es geht um Links, die in per CSS ausgeblendeten Elementen vorhanden sind und ein title-Attribut tragen. Hält man die Maus nun so lange über den Link, dass der title-Tooltip erscheint, verliert der Firefox die Kontrolle über das Element und beim Bewegen der Maus klappt das Element wieder weg. Einfach mal ausprobieren.

Ich konnte bisher nur unter Mac OS X 10.5.4 testen. Ich würde mich freuen, wenn mir ein Windowsnutzer einen kurzen Bericht hinterlassen könnte, da ich für ein Dualbetrieb unter VMWare Fusion noch zu faul war

Nachtrag: Kenny Feldman hat den Bug auch schon entdeckt (und natürlich gemeldet) und ebenfalls eine Testseite eingerichtet.

MooTools 1.2 ist komplett runderneuert, hat eine neue API erhalten und hat sowieso nichts mehr mit der alten 1.11 zu tun (dementsprechend auch nicht kompatibel!).

MooTools 1.2 gibt’s nun als ganzes Paket in Form einer „Core“-Version, die 60 kB groß ist und alle grundlegenden Komponenten enthält. Läuft der eigene Server mit GZIP, hat der Core kann man das Ganze auf gerade mal 18 kB schrumpfen. Neben dieser Version gibt es eine „More“-Version, die man sich in alter Gewohnheit nach Belieben zusammenstellen kann. Allerdings sollte man genau wissen, was man benötigt bzw. was zwingend für bestimmte Anwendungen gebraucht wird.

ABER! Die neue Demo-Seite ist Schrott, aber richtig. Konnte man früher noch bequem in die Codes (JS, HTML, CSS) schauen, muss man sich jetzt das komplette Demo runterladen und lokal durchforsten. Nee, wat bringt das, bitte? Was auch extrem schade ist, dass man mit dem Forum nun zu Google umgezogen ist. Auch nicht das gelbe vom Ei, zumal die tollen Bereiche, wie etwa „Your Scripts“ (hier konnten MooTools-Coder ihre eigenen Plugins anpreisen) fehlen nun völlig.

Jetzt heißt es also wieder reinfuchsen, coden, fluchen, nochmal probieren und Erfolg haben.

Alle nötigen Links, Download, Dokumentation und Demos (auch zur alten 1.11er Version, deren Dokumentation und Demos), zum neuen Github-Repository (Core und More) gibt’s hier.

Keine relevanten Artikel.