macina_banners 1.5.1 Extension ignoriert Sysfolder und zeigt alle Banner an

In der Version 1.5.1 der Extension macina_banners (Advanced Banner Management) scheint es ein Problem mit der Kategorisierung der Banner über mehrere Sysfolder zu geben. In meinem Fall wurden einfach alle Banner angezeigt, unabhängig von der Einstellung, die über typoscript getroffen worden ist. pidList = 123 wird also ignoriert. Das Problem trat in meinem Fall mit einer TYPO3 4.4-Installation auf.

Das Problem scheint im code der Extension zu liegen. Für das Problem ist nämlich bereits ein Fix verfügbar, welcher für die Version 1.5.2 der macina_banners geplant ist und aktuell darauf wartet eingebaut zu werden. Da 1.5.2 schon eine Weile auf sich warten lässt, habe ich den Code manuell übernommen.

Für eine schnelle Abhilfe kann die Extension also direkt editiert werden:

/pfad/zum/webserver/typo3conf/ext/macina_banners/pi1/class.tx_macinabanners_pi1.php

Hier fügen wir hinter den folgenden Zeilen (in Extension-Version 1.5.1 ist das nach Zeile 173)

// alle banner die die aktuelle page id nicht in  excludepages stehen haben
$where .= „AND NOT ( excludepages regexp ‚[[:<:]]“.$GLOBALS[‚TSFE‘]->id.“[[:>:]]‘ )“;

den folgenden Code ein:

// FIX pidList beachten !! Version 1.5.2
if ( $conf[‚pidList‘] != null && $conf[‚pidList‘] != “ )
{
$where .= “ AND pid IN ( „.$conf[‚pidList‘].“ ) „;
}

Weiter Infos:

Fatal error: session_start(): Failed to initialize storage module: files (path: ) in on line

Bei einer aktuellen Debian Linux Installation in Verbindung mit PHP 5.3.3 aus dem Dotdeb-Repository gab es ein Problem mit der Session-Verwaltung:

Fatal error: session_start(): Failed to initialize storage module: files (path: ) in /path/to/php/script/session.inc.php on line 123

Zu lösen war das Problem recht einfach: In der php.ini war die Zeile (session.save_path) auskommentiert. Wird diese einkommentiert

session.save_path = „/tmp“

und der Apache neugestartet, ist das Problem behoben. In anderen Distributionen (OpenSUSE) ist der Speicherort von Haus aus über diese Methode angegeben. Bei einer PHP-Installation aus den Debian-Repositorys tritt das Problem möglicherweise auch nicht in Erscheinung (nicht weiter verfolgt).

Passwort-Reset bei einem HP ProCurve Secure Router 7102dl J8752A

Da die Lösung im HP PDF-Handbuch auf die Schnelle nicht zu finden war: Der Boot ohne Passwort ist bei einem Secure Router 7102dl folgendermaßen möglich:

Im ersten Schritt den Router über ein serielles Kabel mit dem Rechner verbinden. Router sollte ausgeschaltet sein (da wir im Bootvorgang aktiv werden müssen). PuTTY eignet sich als Software hervorragend. Connection type: Serial auswählen; Speed auf 9600 baud belassen). Router einschalten und folgende Meldung abwarten:

Executing bootstrap…
ram: 134217728 bytes of RAM detected.
Serial Number: US511XXXXX
Bootstrap version: J02.01, checksum: 9B84, Tue Mar 29 10:48:20 2005
flash: initializing flash devices…
flash: 33554432 bytes of FLASH detected at 0xfe000000 – dev 0x0001007e
vfs: NONVOL: 504 tracks, 64 sectors/track, 1024 bytes/sector.
eth0/1: initializing…
eth0/1: MAC address is 00:XX:XX:XX:XX:XX
bootstrap: Checking boot configuration…
bootstrap: Primary image is ‚NONVOL:/J02_01.biz‘.
You have 5 seconds to press escape to enter bootstrap mode.

An dieser Stelle ESC drücken

bootstrap: User escaped to command line interface.
cli: starting user interface

Press ‚?‘ for help.
bootstrap#

bypass passwords
boot

Der Zugriff auf den Router ist danach ohne Passwort möglich und man kann ein neues Passwort vergeben.