Medienbeckerei Blog

Ich habe in einem Projekt von mir ein Problem gehabt, ein Wert aus der Session, die ich in einer Datei deklariert hatte, in einer anderen Datei aus der Session wieder auszulesen. Die Session war leer. Das Beispiel:

In der Datei “login.php”:

$_SESSION['user'] = ‘Herbert’;

header(“Location: start.php”);

In der Datei “start.php”:

session_start();
print_r ($_SESSION);

Die Ausgabe war dann “Array()” (also ein leeres Array). Eine PHPSESSID bestand aber (SID wurde also angelegt). Woran lag das?

Dieser Artikel hat mir geholfen, der besagt, dass der Webuser keine Berechtigung hat in die “/var/sessions” zu schreiben (sollte man mit “chmod 777 /var/sessions” beheben oder mit seinem Provider absprechen). Desweiteren hat der Artikel mir gezeigt, dass man auch die SID per URL übertragen kann (wenn Cookie-basiertes Handling nicht zur Verfügung steht). Dazu muss SID dann als erstes nach dem “?” in der URL angegeben werden (Bsp.: “daten.php?sid=12&weitere=angaben….”).

Ansonsten kann man (wenn der Provider das zur Option stellt) noch in der php.ini folgende Angaben machen:

session.use_only_cookie = 0

session.use_trans_sid = 1

session.use_cookie = 1

Mir gefiel die Art und Weise des normalen Wordpress Logins in einem meiner aktuellen Projekte nicht. Also habe ich mich umgeschaut, welche Formen es noch gibt. Da bin ich auf die Idee gestoßen, eine Art Overlay (wie man es von Thickbox, Lightbox, Slimbox, etc kennt)  dafür zu nutzen.

Dann habe ich den Artikel gelesen, in dem jQuery, Thickbox und Wordpress dafür vereinigt werden. Um nicht im Header rumfummeln zu müssen, habe ich mir kurzerhand ganz bequem das Thickbox Plugin installiert.

Dazu mußte ich dann noch folgende Schritte erledigen:

In dem aktivierten Themes Verzeichnis hab ich in die sidebar.php den Code für das Formular aus meiner wp-login.php reinkopiert:

<div id=”form” style=”display:none;”>

<form name=”loginform” id=”loginform” action=”<?php echo site_url(‘wp-login.php’, ‘login_post’) ?>” method=”post”>
<p>
<label><?php _e(‘Username’) ?><br />
<input type=”text” name=”log” id=”user_login” value=”<?php echo esc_attr($user_login); ?>” size=”20″ tabindex=”10″ /></label>
</p>
<p>
<label><?php _e(‘Password’) ?><br />
<input type=”password” name=”pwd” id=”user_pass” value=”" size=”20″ tabindex=”20″ /></label>
</p>
<?php do_action(‘login_form’); ?>
<p><label><input name=”rememberme” type=”checkbox” id=”rememberme” value=”forever” tabindex=”90″ /> <?php esc_attr_e(‘Passwort speichern’); ?></label></p>
<p>
<input type=”submit” name=”wp-submit” id=”wp-submit” value=”<?php esc_attr_e(‘Anmelden’); ?>” tabindex=”100″ />
<input type=”hidden” name=”redirect_to” value=”<?php echo esc_attr(admin_url()); ?>” />
<input type=”hidden” name=”testcookie” value=”1″ />
</p>
</form>
</div>

Dann habe ich etwas über diesem Code in der sidebar.php den Standardeintrag von Wordpress durch folgendes ersetzt, damit das neue Formular auch korrekt aufgerufen wird, jedoch während des eingeloggten Zustands das “normale” Standardelement (Admin und Abmelden) dennoch vorhanden ist:

<?php if ( !is_user_logged_in() ) {
echo “<li><a href=\”#TB_inline?height=180&amp;width=200&amp;inlineId=form\” class=\”thickbox\” title=\”Dein Loginformular\” rel=\”nofollow\”>Login</a></li>”;
}else{
echo “<li>”.wp_loginout().”</li>”;
} ?>

In meinem ausgesuchten Theme gab es oben in der header.php noch ein Anmelde-Icon, welches ich auch kurzerhand etwas modifiziert habe:

<?php if ( !is_user_logged_in() ) { echo “<a href=\”".get_bloginfo(‘url’).”/wp-content/themes/purple/sidebar.php#TB_inline?height=180&amp;width=200&amp;inlineId=form\” class=\”thickbox\” title=\”Dein Loginformular\” id=\”login\” rel=\”nofollow\”>Login</a>”; } ?>

Daran denken, dass Google immer den Login indiziert, was natürlich unnötig ist. Somit rel=”nofollow” mit in dem Link angeben (wie oben geschehen).

Sodann hat man ein fesches Ajax Anmeldeformular und alles wird gut.

Kleine Anmerkung: damit man beim Logout nicht doch das “normale” Standard Anmeldeformular sieht, benötigt man ab Zeile 312 in wp-login.php noch folgende Ergänzung:

case ‘logout’ :
check_admin_referer(‘log-out’);
wp_logout();

//$redirect_to = ‘wp-login.php?loggedout=true’;
//if ( isset( $_REQUEST['redirect_to'] ) )
//    $redirect_to = $_REQUEST['redirect_to'];

//wp_safe_redirect($redirect_to);
wp_safe_redirect(“/”);
exit();

Nach dem ich mal wieder etwas Zeit hatte, dachte ich mir, dass ich meine Plugins ja mal auf den neuesten Stand bringen könnte. Gesagt getan, so klickte ich im Admin Menue jedes Plugin an, welches danach schreite. Ab dem 12ten gab es dann plötzlich ein Problem. Fehlermeldung “Fatal error: Allowed memory size of 33554432 bytes exhausted”.

Da sollte man dann einfach in der Datei wp-config.php den Wert ‘WP_MEMORY_LIMIT’ in der folgenden Zeile “define(’WP_MEMORY_LIMIT’, ‘32M’);” auf 64M hochzusetzen. Matthias Mayer’s Blog beschreibt noch andere Fehlerquellen und Lösungen zum Speicherproblem unter Wordpress.

Wenn man einen “Routing error” erhält, kann ein Eintrag in der

“config/routes.rb” falsch sein. Dort kann man nach dem

folgenden Muster die Route angeben (am besten ganz oben):

map.connect ”, :controller =>’companies’, :action =>’index’

First:

pg_dumpall > outfile

then:
psql -U "owner name" dbname < infile
(or: psql -f infile postgres)

Once restored, it is wise to run ANALYZE on each database so the optimizer has useful statistics. An easy way to do this is to run:

"vacuumdb -U 'owner name' -a -z"

to VACUUM ANALYZE all databases; this is equivalent to running VACUUM ANALYZE manually.