Beiträge von Putzlowitsch

Soll da denn die Uhrzeit angezeigt werden, zu der des letzt Bild der Webcam aufgenommen wurde? Ist das einfach ein festes Bild, was nur in regelmäßigen Abständen aktualisiert wird? Falls ja, geht das auch z.B. mit einem Shortcode und ein bißchen PHP.

Gruß
Ingo

Falls die Bilder nur in den jeweiligen Seiten eingebunden sind, reicht bereits ein noindex für die Seiten mit den Bildern. Damit wird Google ja angewiesen, die Seite nicht bei der Suche zu berücksichtigen. Da Bilder aber ohne verlinkende/einbindende Seite nicht in der Bildersuche angezeigt werden, können die Bilder nicht mehr in der Bildersuche erscheinen.

Falls die Seiten selbst zwar im normalen Suchindex, nicht aber im Bilderindex erscheinen sollen, gibt es sogar den speziellen Meta-Eintrag 'noimageindex':
https://support.google.com/webmasters/answer/79892?hl=de

Mein diesbezüglicher Test vor einiger Zeit hat ergeben, daß es nach anfänglichen Problemen tatsächlich funktioniert.

Man muß sich immer vergegenwärtigen, daß die Google-Bildersuche als Ergebnis keine Bilder, sondern Seiten mit den Bildern liefert. Es muß also mindestens eine erlaubte Quelle für ein Bild geben, also eine Seite, die das Bilde verlinkt oder per img-Tag einbindet, die selbst nicht für den Index gesperrt ist.

Letztendlich ist aber der schneller Weg, die Bilder tatsächlich in der robots.txt und in den Google-Webmastertools zu sperren. Es dauert dann nur einige Stunden, bis die Bilder aus dem Index verbannt sind.

Gruß
Ingo

Melewo
Es geht um die WP-internen Regeln. In der .htaccess ist das tatsächlich fast immer gleich.

Ich habe vor langer Zeit mal ein PHP-Skript erstellt, welches die WP-RewriteRules ausgibt:

<?php
define('WP_USE_THEMES', false);
require('./wp-blog-header.php');
echo '<pre>';
print_r( $wp_rewrite->wp_rewrite_rules() );
echo '</pre>';
?>

Sehr einfach gehalten, aber funktioniert. :-)

Bei mir stehen da am Anfang Regeln, die mit 'category/' beginnen.

Gruß
Ingo

Zitat von Melewo

...
Ab der WP-Version 3.5.2 wurde bereits die PHP Version 5.2.4 vorausgesetzt für eine fehlerfreie Funktionsweise. Dein Server verwendet aber noch 5.2.17...

Naja, PHP 5.2.17 ist aber die neuere Version, PHP 5.2.4 die deutlich ältere. Meines Wissens ist die 5.2.17 auch die aktuellste Version im 5.2-Zweig. Daran sollte es also nicht liegen.

Komisch ist das aber schon, möglicherweise sind die internen WP-Rewrite-Rules fehlerhaft, ein Plugin funkt dazwischen oder was auch immer.

Gruß
Ingo

Hast Du das verlinkte Plugin ausprobiert?

Gruß
Ingo

Der "./"-Trick funktioniert nur unter bestimmten Bedingungen:
http://faq.wpde.org/kategoriebasie…-url-entfernen/

So muß z.B. im der Permalink-Struktur mit /%category%/ beginnen und auch die Artikel-ID enthalten.
Es gibt aber auch Plugins, welche die "Kategorie-Basis" enfernen, z.B.:
http://wordpress.org/plugins/no-category-base-wpml/

Gruß
Ingo

Genau so macht es AntispamBee ja auch, Bots mit zusätzlichen/geänderten Feldern in die Fall locken. Die Frage ist ja nur, ob diese Kommentare dann per Einstellung sofort gelöscht werden sollen oder eben nur als Spam markiert werden. Das kann man meines Wissens sehr detailiert konfigurieren.

Gruß
Ingo

Seit Wordpress 3.5 gibt es keine Linkverwaltung (Blogroll) mehr. Du müßtest das mit einem Plugin nachrüsten:
http://blog.wpde.org/2012/10/09/blo…ern-kannst.html

Gruß
Ingo

Ein Klassiker. :-)
Die Antwort findest Du hier:
http://faq.wpde.org/statische-startseite-und-artikelliste/

Gruß
Ingo

Funktioniert ja nun, wenn ich das richtig sehe.
Bei Änderungen am DNS muß man etwas Geduld haben, bis diese auch tatsächlich wirksam werden.

Gruß
Ingo

Das größte Problem dürft sein, daß Du in der robots.txt allen Bots den Zugriff auf Deine Seiten verbietest.

User-agent: *
Disallow: /

Seriöse Bots halten sich daran. Da helfen dann auch keine Sitmap, Plugins oder andere Verrenkungen.

Gruß
Ingo

Zitat von Monika

...
bei deinem jetzigen Hoster ist eine korrekte Weiterleitung nicht möglich
...

Wieso nicht? BPlaced scheint ja das Aufschalten externen Domains zu erlauben, sonst würde es ja auch nicht mit www funktionieren. Und bei United-Domains sollte man auch den A-Record für die Second-Level-Domain (SLD) ändern können. Ich sehe da kein größeres Problem.

Gruß
Ingo

Na das mit dem Redirect in der .htaccess wird nicht wirklich helfen. Das Problem ist, daß für den Domain-Namen ohne etwas davor (z.B. www) keine IP-Adresse gefunden wird. Also weiß der Webbrowser auch nicht, wo er die Anfrage hinschicken soll. Das es beim manchen Browsern klappt liegt daran, daß die einfach selbst die Domain mit www aufrufen, falls ohne keine IP-Adresse ermittelt werden kann.

Um das Problem zu lösen, muß beim Domain-Hoster (United-Domains) ein A-Record mit der IP des Servers bei bplaced angelegt werden (hatte formateins ja bereits geschrieben). Es scheint dort einen Wildcard-CNAME Eintrag auf blpaced zu geben, der aber eben nur bei Subdomains funktioniert. Etwas anderes ist www auch nicht. Da meist ein CNAME-Eintrag für die SLD nicht möglich ist, hilft hier nur der A-Record mit der IP-Adresse des Hosting-Servers.

Gruß
Ingo

Du mußt natürlich auch die Subdomain in Strato-Menü anlegen und auf das selbe Verzeichnis zeigen lassen, wie die Hauptdomain (also die WP-Installation). Strato unterstützt in den Webhostingpaketen meines Wissen keine Wildcard-Subdomains.

Gruß
Ingo

Was meinst Du mit "wo bei die geforderte Funktion nicht gegeben ist"?

Bei Deiner Variante wird fast am Anfang geprüft, ob es ein Artikel-Passwort gibt und ob ein dazu passender Cookie existiert. Falls nicht, wird der Kommantarbereich nebst Eingabeformular nicht angezeigt, statt dessen eine Meldung.

Ansonsten kommt dort auch die normale Kommantarausgabe und das Formular. Beim Twenty-Twelve sind diese Sachen halt nur in Funktionen ausgelagert und stehen nicht in der comments.php direkt drin.

Möglicherweise stimmt bei Dir da was mit der Auswertung des Cookies nicht (z.B. Cookie-Name).

Gruß
Ingo

Ahh sorry, hatte ich oben übersehen. Setz mal beide Adressen auf die co.uk-Domain.

Gruß
Ingo

Bei Anbieter A muß der Webspace so konfiguriert sein, daß die Domain von Anbieter B genau auf das en-Verzeichnis als Domain-Root zeigt.

Gruß
Ingo

In der Tabelle findest Du weit oben einen Eintrag "Loaded Configuration File" und dort steht nicht die 1&1-php.ini drin, sondern Deine (/homepages/20/.../Wordpress_KdL/wordpress/php.ini).

Außerdem findest Du unter Core ja bei "post_max_size" und "upload_max_filesize" genau die Werte, die Du eingestellt hast (40M bzw. 50M). Deine php.ini wird also geladen und ist aktiv.

Die php.ini direkt im Verzeichnis /wp-admin/ sollte reichen. Versuch ggf. auch mal den "Browser Uploader" direkt in der Mediathek bei "Datei hinzufügen".

Ich habe da mal bei mir ein 38M PDF-Testdatei hochgeladen (beide Wert vorher in der php.ini auf 60M gesetzt). Hat zwar eine gefühlte Ewigkeit gedauert, aber dann doch funktioniert.

Gruß
Ingo

Ja, es gibt in der Funktion einen Filter-Hook. Um das Auslesen (bzw. Zurückgeben) der Metadaten zu unterbinden, sollte folgendes reichen:

function my_read_image_metadata( $meta, $file, $sourceImageType ) {
  return false;
}
add_filter( 'wp_read_image_metadata', 'my_read_image_metadata', 10, 3 );

Gruß
Ingo

Hast Du auch die Änderungen gemäß FAQ durchgeführt?
http://faq.wpde.org/wordpress-url-aendern/

Gruß
Ingo