Na, dann läuft das Script jetzt wenigstens mit gzip Ausgabe. Solche Provider-Probleme sind eine andere Baustelle (Strato ?).
CMS-Seiten werden von diesem Script nicht ausgegeben. Das will z.B. ich auch garnicht, sondern nur artikelbezogene Links zum Verkauf.
In der Datei robots.txt sind ausserdem noch andere Ausschlüsse möglich.
Hallo Earlybird,[QUOTE=Earlybird;94029]Solche Provider-Probleme sind eine andere Baustelle (Strato ?).[/QUOTE]Nein, nicht Strato, eigentlich hatte ich noch keine Probleme in diese Richtung. Ich finde es ja richtig, wenn nur die Module frei geschalten sind, die auch benötigt werden. Nur wenn man sich nicht so richtig mit PHP auskennt…
[QUOTE=Earlybird;94029]CMS-Seiten werden von diesem Script nicht ausgegeben. Das will z.B. ich auch garnicht, sondern nur artikelbezogene Links zum Verkauf.[/QUOTE]Ich nahm das an, weill weiter oben die Rede davon war und ich im Script die
function getCmsSite()
gesehen habe und auch davon, dass die Sitemap aufgeteilt werden kann…
Danke nochmals
Gert
Ja stimmt, das steht im Code, gibt aber keine CMS Links in der Sitemap aus.
Wie gesagt:
Es handelt sich hier um eine “beta_version” open source und jeder kann daran weiterprogrammieren was er will. Da ich CMS in der sitemap nicht brauche, habe ich mich darum auch nicht weiter gekümmert.
Daher ja der Wunsch, dass das Thema sitemap endlich mal von Oxid als Standard intergiert wird und das ist bereits bei Oxid angekommen.
[QUOTE=Earlybird;91687]
2. Nach Löschen der oxseo Daten (z.B. zur Bereinigung alter Daten, zu grosse Tabelle) oder beim Direkt-Import von Artikeln in die Datenbank (ohne Oxid-Importfunktion), kann mit dem gen. Export die oxseo neu geschrieben werden - das war mein Sonderfall.[/QUOTE]
Könntest Du das noch einmal näher erläutern? Wie läuft der Neuaufbau der Tabelle oxseo durch einen generischen Export ab?
Danke für Aufklärung!
Wenn man in einem Sonderfall die MySQL-Tabelle oxseo leeren möchte oder muss - also genau weiß man tut - dann wird durch Ausführung des “gen. Export” (im Admin) die oxseo automatisch komplett neu geschrieben - das kann man so einfach als Nebeneffekt nutzen.
Anderenfalls wird eine leere oxseo erst durch den Besuch der Shop-Seiten über das Frontend im Laufe der Zeit neu geschrieben.
Ok, danke. Das entspricht also nicht dem Button “SEO URLs neu berechnen” in den Einstellungen, oder? Was ist genau der Unterschied?
Anderenfalls wird eine leere oxseo erst durch den Besuch der Shop-Seiten über das Frontend im Laufe der Zeit neu geschrieben.
…und in diesem Fall funktioniert natürlich der hier dargestellte sitemap-xml-Ansatz überhaupt nicht mehr.
Der Unterschied ist:
Der generische Export aktualisiert die ganze Tabelle oxseo bzw. schreibt eine leere oxseo komplett neu.
Der Button “SEO URLs neu berechnen” bewirkt dagegen nur, dass beim Aufruf einer Seite deren SEO URL neu berechnet wird. Siehe auch Handbuch PDF ab Seite 48 ff mit mehr Info.
Hallo,
nachdem das Script läuft, versuche ich gerade einen Cron dafür einzurichten. Dafür habe ich mir eine Text-datei mit allen Crontabs erstellt, die ich mit putty aufrufe.
Das funktioniert prinzipiell, nur der neue Eintrag für die Sitemap will noch nicht. Ich erhalte hier: “.txt”:14: premature EOFerrors in crontab file, can’t install."
05 00 * * * perl /srv/www/xxxx/yyyy/mysqldumper/./../../cgi-bin/crondump.pl -config=ddddd -html_output=0
10 00 * * * perl /srv/www/xxxx/yyyy/mysqldumper/./../../cgi-bin/crondump.pl -config=ddddd -html_output=0
15 00 * * * perl /srv/www/xxxx/yyyy/mysqldumper/./../../cgi-bin/crondump.pl -config=ddddd -html_output=0
20 00 * * * perl /srv/www/xxxx/yyyy/mysqldumper/./../../cgi-bin/crondump.pl -config=ddddd -html_output=0
25 00 * * * perl /srv/www/xxxx/yyyy/mysqldumper/./../../cgi-bin/crondump.pl -config=ddddd -html_output=0
30 00 * * * perl /srv/www/xxxx/yyyy/mysqldumper/./../../cgi-bin/crondump.pl -config=ddddd -html_output=0
35 00 * * * perl /srv/www/xxxx/yyyy/mysqldumper/./../../cgi-bin/crondump.pl -config=ddddd -html_output=0
40 00 * * * perl /srv/www/xxxx/yyyy/mysqldumper/./../../cgi-bin/crondump.pl -config=ddddd -html_output=0
45 00 * * * perl /srv/www/xxxx/yyyy/mysqldumper/./../../cgi-bin/crondump.pl -config=ddddd -html_output=0
50 00 * * * perl /srv/www/xxxx/yyyy/mysqldumper/./../../cgi-bin/crondump.pl -config=ddddd -html_output=0
55 00 * * * perl /srv/www/xxxx/yyyy/mysqldumper/./../../cgi-bin/crondump.pl -config=ddddd -html_output=0
00 01 * * * perl /srv/www/xxxx/yyyy/mysqldumper/./../../cgi-bin/crondump.pl -config=ddddd -html_output=0
05 01 * * * perl /srv/www/xxxx/yyyy/mysqldumper/./../../cgi-bin/crondump.pl -config=ddddd -html_output=0
10 01 * * * perl /srv/www/xxxx/wwww/sitemap/google_sitemap_xml.sh -c 1
M.E. kann es nur entweder am
mfg
Gert
Probier mal statt:
google_sitemap_xml.sh -c 1
folgendes:
google_sitemap_xml.php
Hallo Earlybird[QUOTE=Earlybird;94639]Probier mal statt:
google_sitemap_xml.sh -c 1
folgendes:
google_sitemap_xml.php[/QUOTE]negativ…
PS: ich glaube, dass der Cron mit PHP nicht funktioniert. Bei mysqldumper musste auch die Perlstrecke richtig eingerichtet werden, ehe die Cronjobs liefen.
mfg
Gert
LÖSUNG
Skripte mit passendem Interpreter starten:
Für ein PHP-Skript unter /home/username/bin/beispiel.php sieht das Cron-Kommando z.B. wie folgt aus:
PHP: /usr/local/bin/php -f /home/username/bin/beispiel.php
Für andere Skripte:
Perl: /usr/local/bin/perl /home/username/bin/beispiel.pl
Python: /usr/local/bin/python /home/username/bin/beispiel.py
Ruby: /usr/local/bin/ruby /home/username/bin/beispiel.rb
Pfade individuell anpassen.
Ich habe bei mir eben nochmal in der sitemap nachgeschaut. Bei mir werden die CMS-Seiten mit ausgegeben. Ist für uns auch wichtig, wegem dem ausführlicherem Content.
Bei mir erstellt das Skript erwartungsgemäß folgende Dateien:
[ul][li]sitemap-de.xml[/li][li]sitemap-de1.xml.gz[/ul][/li]
Erstere verweist auf letztere. Aber ein paar Fragen hätte ich noch:
Auf support.google.com wird das nur sehr allgemein erklärt. 
[QUOTE=Earlybird;94624]Der Unterschied ist:
Der generische Export aktualisiert die ganze Tabelle oxseo bzw. schreibt eine leere oxseo komplett neu.
Der Button “SEO URLs neu berechnen” bewirkt dagegen nur, dass beim Aufruf einer Seite deren SEO URL neu berechnet wird. Siehe auch Handbuch PDF ab Seite 48 ff mit mehr Info.[/QUOTE]
Danke für den Hinweise auf das Handbuch; das müßte dann noch mit dem Tip für den generischen Export ergänzt werden.
Hast Du eine Idee, wie man den Neuaufbau von oxseo, den der generische Export bewirkt, irgendwie von außen triggern kann? Hintergrund ist, dass ich den klassischen Wawi-Fall habe, d.h. die Artikeldaten werden neu geschrieben und die oxseo ist sozusagen ungültig.
@ Thorsten Albrecht,
Antwort:
2.1. libresk_sitemap.php (open source)
2.2. http://www.marmalade.de/informationen/impressum.html (contribution angesagt)
2.3. http://shop.fatchip.de/OXID-Modul-Google-XML-Sitemap.html (kommerziell, schon fertig)
Was sagst Du dazu, was hast Du vor?
Hallo Earlybird,[QUOTE=Earlybird;94663]LÖSUNG
Skripte mit passendem Interpreter starten:
Für ein PHP-Skript unter /home/username/bin/beispiel.php sieht das Cron-Kommando z.B. wie folgt aus:
PHP: /usr/local/bin/php -f /home/username/bin/beispiel.php
Für andere Skripte:
Perl: /usr/local/bin/perl /home/username/bin/beispiel.pl
Python: /usr/local/bin/python /home/username/bin/beispiel.py
Ruby: /usr/local/bin/ruby /home/username/bin/beispiel.rb
Pfade individuell anpassen.[/QUOTE]
Also bei mir konnte ich den Cronjob mit:
10 01 * * * /usr/lib64/php5/5.3.3/bin/php /srv/www/xxx/sitemap/google_sitemap_xml.php
anlegen.
Nun muss der Provider nur noch heraus finden, warum er nicht läuft…
mfg
Gert
Moin,
Also bei mir konnte ich den Cronjob mit:
10 01 * * * /usr/lib64/php5/5.3.3/bin/php /srv/www/xxx/sitemap/google_sitemap_xml.php
anlegen.Nun muss der Provider nur noch heraus finden, warum er nicht läuft…
Schreib mal ein [email protected] vor der Zeile, dann solltest du in der Regel eine Mail mit der Fehlermeldung bekommen.
Ich würde statt 01 eher 1 schreiben.
cyrano
Hallo Helfer,
und alle Interessierten.
Es ist zumindest bei meinem Provider egal, ob der Cronjob als .php oder als .sh angelegt wird. Allerdings kommt hier bei beiden eine Fehlermeldung. Die Funktion “system():” ist auch Sicherheitsgründen für Cronjobs vom Provider abgeschalten.
Nun hat der Provider gesagt, dass ich eine eigene php.ini übergeben kann. Das übersteigt nun etwas meine Kenntnisse…
Ich habe mich für php entschieden und, weil die gepackte Datei ja nicht bei jedem Cronjob neu erstellt wird und somit für Google nich relevant ist, die gzip-Funktion (Zeile 325 - 333 und Zeile 108) auskommentiert.
Bei
$mod_cnf['filepath'] = '';
habe ich die URL, wie in dern config_inc.php
$this->sShopDir = '';
eingegeben, weil sonst beide xml.Dateien im Server-Root abgelegt werden - wenn
$mod_cnf['filepath'] = '';
Nun wird die sitemap-de1.xml im Ordner “/sitemap/” erstellt, nur die “sitemap-de.xml” wird im Server-Root (mit falscher Weiterleitung auf die “sitemap-de1.xml.gz”) erstellt. Der Cronjob bei mir lautet:
MAILTO=info@email
10 01 * * * /usr/lib64/php5/5.3.3/bin/php /srv/www/root/ordner/sitemap/google_sitemap_xml.php -c 1
#
Eine Email erhalte ich nur, wenn der Cronjob nicht ausgeführt werden kann.
mfg
Gert
[QUOTE=Earlybird;95213]@ Thorsten Albrecht,
Antwort:
2.1. libresk_sitemap.php (open source)
2.2. http://www.marmalade.de/informationen/impressum.html (contribution angesagt)
2.3. http://shop.fatchip.de/OXID-Modul-Google-XML-Sitemap.html (kommerziell, schon fertig)
Was sagst Du dazu, was hast Du vor?[/QUOTE]
Hallo,
2.2 verstehe ich nicht so richtig. Wie? Was? Contribution?
Gruß Joscha
müsste in zeile 328 beim gzip nicht noch der param -f gesetzt werden, damit die Sitemap immer überschrieben wird? 