Klarer Fall, die Kommentarzeit entspricht exakt der Beitragserstellungszeit. Da steht vermutlich im Theme fälschlicherweise the_time(...) anstelle von comment_date(...).
Gruß
Ingo
Um schreiben oder kommentieren zu können, benötigen Sie ein Benutzerkonto.
Sie haben schon ein Benutzerkonto? Melden Sie sich hier an.
Jetzt anmeldenHier können Sie ein neues Benutzerkonto erstellen.
Neues Benutzerkonto erstellenKlarer Fall, die Kommentarzeit entspricht exakt der Beitragserstellungszeit. Da steht vermutlich im Theme fälschlicherweise the_time(...) anstelle von comment_date(...).
Gruß
Ingo
Putzlowitsch: <a href="[PERMALINK]" class="more-link">Weiterlesen</a>
Passt schon. ;-)
Ja, stimmt. Aber das mit dem Background sollte funktionieren :-)
Tut es zumindest bei mir, hab es grad getestet. Da klappt interessanterweise auch folgendes:
Gibt zwar nach einer weile Augenschmerzen, aber ich habe wohl keine spezifischeren Regeln, die das wieder überstimmen.
Gruß
Ingo
Geht nicht, gibts nicht :-)
Mal wieder ein schneller Hack für die my-hacks.php:
function plw123_upw_init() {
if( isset($_GET['post_password']) ){
if( get_magic_quotes_gpc() )
$_GET['post_password'] = stripslashes($_GET['post_password']);
// 10 days
setcookie('wp-postpass_' . COOKIEHASH, $_GET['post_password'], time() + 864000, COOKIEPATH);
$_COOKIE['wp-postpass_' . COOKIEHASH] = $_GET['post_password'];
}
}
add_action( 'init', 'plw123_upw_init' );
Beim Aufruf der Seite einfach ?post_password=geheim anhängen. Also z.B. so:
http://schnurpsel.de/test/?post_password=geheim
Das Passwort natürlich den eigenen Gegebenheiten anpassen. Der Code stammt übrigens im wesentlichen aus der wp-pass.php.
Gruß
Ingo
Genau sowas meinte ich oben mit "Wordpress-Anmeldung", also im weitesten Sinne :-)
Nein, das wird so wohl nicht funktionieren, es sei denn, mit einem Plugin, welches aus der URL das Passwort extrahiert und dann an WP entsprechend weitergibt. Da ist mir aber nichts bekannt.
Gruß
Ingo
Mit den Permalinks wohl eher nicht, aber WP kann von Hause aus erstmal nichts mit Keywords anfangen. Dafür muß man ein Plugin bemühen. Ob das dann allerdings mit MarsEdit zusammenspielt? Keine Ahnung.
Gruß
Ingo
nee, keine WordPress-user-Anmeldung, sondern nur Passwort für eine passwortgeschützte Seite.
Nur Passwort? Also ein Username ist, glaub ich, auch erforderlich und dann sollte es so gehen, wie von mir aufgezeigt. Nur im IE7 geht das wohl nicht mehr. Test:
http://username:password@putzlowitsch.de/test/
Normalerweise sieht das so aus:
http://username:password@example.org
Das funktioniert aber nur bei der Standardauthentifizierung (z.B. über .htaccess), ich denke aber nicht mit einer Wordpress-Anmeldung.
Gruß
Ingo
Die Links werden mit get_permalink erzeugt.
Putzlowitscher Zeitung » 123 Intlink
Gruß
Ingo
Naja, ich verwende da so ein kleines Plugin, das interne Verlinkungen über ein Quicktag anhand der ID einfügt. Das klappt bei Beiträgen und Seiten und der Link paßt immer auch bei geänderten Strukturen.
Man muß halt nur die ID kennen. Ist also nicht komfortabel mit Auswahlliste und so.
Gruß
Ingo
Hallo Edalon,
habe meine Beschreibung auf schnurpsel.de überarbeitet und noch einen Kommentar geschrieben. Das sollte das Problem mit den drei letzten Einträgen lösen.
Gruß
Ingo
Was ist denn mit Plugins? Da gibt es auch manche, die in die Permalinkgeschichte eingreifen.
Gruß
Ingo
So richtig habe ich keine Idee, außer das irgendein Plugin querschießt.
Falls sich mal jemand seine Rewrite-Rules ansehen will, einfach eine PHP-Datei (z.B. show-rwr.php) mit folgendem Inhalt erstellen:
<?php
define('WP_USE_THEMES', false);
require('./wp-blog-header.php');
echo '<pre>';
print_r( $wp_rewrite->wp_rewrite_rules() );
echo '</pre>';
?>
Diese in das WP-Wurzelverzeichnis kopieren und aufrufen. Ist schon beeindruckend, was da alles so drin steht, gerade wenn man viele statische Seiten hat.
Gruß
Ingo
...
Version ist 2.2.2, Mysql hat MySQL 4.0.24_Debian-10sarge2-log
...
Achso, hätte ja sein können, das es die Option 'rewrite_rules' z.B. bei WP 2.0.x nich nicht gab, und sie deshalb nicht zu finden ist.
Das die Regeln überhaupt in der wp_options stehen, wird wohl nur aus Performancegründen gemacht, denn sie werden sonst auch bei jedem Seitenaufruf "on-the-fly" generiert. Es müßte also auch alles funktionieren, wenn es den Eintrag nicht in der Tabelle gibt.
Gruß
Ingo
'rewrite_rules' gibt es gar nicht? Das ist aber seltsam. Die werden normalerweise automatisch bei Änderungen an den Permalinks oder beim Erstellen einer Seite erzeugt. Und sogar dann, wenn sie beim Aufruf der Seite nicht existiert. Habe es grade probiert, wenn ich sie in der Datenbank lösche, sind sie nach einem Aufruf der Seite wieder da.
Manuell nachholen geht nicht, das ist zu kompliziert.
Welche WP Version ist das denn?
Gruß
Ingo
Da werden vielleicht, warum auch immer, die 'rewrite_rules' nicht oder nicht vollständig in die wp-options-Tabelle geschrieben. Ist denn irgendein Plugin aktiv, welches da einen Einfluß haben könnte?
Für die statischen Seiten selbst ist es übrigens egal, was da in den Permalinkeinstellungen steht (ob mit ID oder ohne), das wirkt nur auf die Beiträge. Die Adresse für Seiten wird immer nur aus dem %postname% gebildet, gegebenfalls zusammengesetzt aus der hierarchischen Seitenstruktur.
In den Rewrite-Rules steht für jede Seite eine Regel, die genau auf den Postname paßt. Fehlt diese, kann die Seite nicht aufgelöst werden. Ich hatte so einen Effekt mal beim 'spiegeln' der Daten von meiner Webseite in meine lokales Testsystem. Da lasse ich die wp-options-Tabelle immer weg, weil ich im Testsystem teilweise andere Einstellngen verwende. Dadurch wurden dann aber auch die Rewerite-Rules nicht mit übertragen, so das eine im Web neu angelegte statische Seite im lokalen System auch eine 404er brachte.
Guck doch mal direkt in der wp-options-Tabelle in der Option 'rewrite_rules' im Feld 'option_value', ob da der Permalink zu einer der statischen Seiten drinsteht. Wenn die Seite z.B. den postname meine-eine-seite hat, dann müßt dort sowas zu finden sein: (meine-eine-seite)(/[0-9]+)?/?$
Gruß
Ingo
Gibt es dort sogar schon eine Weile als Idee:
WordPress › Extend › Ideas — Toggle visibility of Pages
Und das hier gerade diskutierte Verfahren wurde dort auch schon mal angedeutet:
WordPress › Extend › Ideas — Toggle visibility of Pages
Vieleicht wird es ja mal was...
Gruß
Ingo
Es kann aber auch durchaus Konstellationen geben, wo die alleinige Verwendung von /%postname%/ zu Problemen führt:
Using Permalinks « WordPress Codex
Ist jetzt zwar nicht dirket das hier geschilderte Problem, aber könnte in die Richtung gehen.
Du könntest ja mal versuchsweise /%postname%-%post_id%/ nehmen und gucken, ob das Problem dann nicht mehr besteht.
Gruß
Ingo
...
Das hängt ja von Einstellungen -> Permalinks ab. Was ist dort eingetragen? Das ggf. mal ändern.
... Ansonsten, wie schon beschrieben, einen anderen Permalink-Typ wählen
Da kann man nicht viel ändern. Wenn Permalinks verwendet werden, dann wird für Seiten immer /%postname%/ benutzt, gegebenfalls zusammengesetzt aus der hierarchischen Seitenstruktur. Die speziellen Einstellungen mit den vielen Tags gelten nur für Beiträge.
Andererseits war das mit dem "versteck" nur ein Beispiel. Wenn man von vorn herein da einen passenden Namen einplant, ist das kein Problem. Aber wenn ich das jetzt bei mir nachträglich verwende, stimmen ja die schon weltweit bekannten Links meiner Seiten nicht mehr und ich müßte mir wieder irgendwas mit Redirect zusammenbasteln.
Unabhängig davon ist es aber eine feine Lösung für ein Problem, was man ja sonst nur mit PHP-Rumgefummel hinbekommt. Andererseits wäre es schön, wenn Wordpress (vielleicht ja schon in 2.3) eine Option mitbringt, mit der man einfach Seiten auf sichtbar oder versteckt schalten kann. Scheint ja doch öfter mal vorzukommen, daß man nicht alle Seiten auch im Menü haben will.
Gruß
Ingo