News:

Wondering if this will always be free?  See why free is better.

Main Menu

Höchst seltsamer Problem...

Started by Medizinmann99, August 30, 2006, 02:49:09 PM

Previous topic - Next topic

xenovanis

Quote from: Medizinmann99 on September 01, 2006, 07:49:08 AM
Auf die Schnelle finde ich nur eine .htaccess und zwar im Unterordner Attachments.

Das habe ich jetzt dort hinzugefügt. Die sieht jetzt insgesamt so aus:

<Files *>
   Order Deny,Allow
   Deny from all
   Allow from localhost
</Files>
<IfModule mod_security.c>
   # Turn off mod_security filtering.  SMF is a big boy, it doesn't need its hands held.
   SecFilterEngine Off

   # The below probably isn't needed, but better safe than sorry.
   SecFilterScanPOST Off
</IfModule>

Das ist ihm völlig wurscht, prescription geht immer noch nicht.

Nee, aber das geht aucht nicht. Du brauchst die .htaccess im Forum-root oder Site-root. Wann es keiner gibt, sollst du selbst ein kreieren.
"Insanity: doing the same thing over and over again and expecting different results."

xduugu

Quote from: Medizinmann99 on September 01, 2006, 07:45:50 AM
Gut ich versuche das jetzt. Ich hoffe es gibt nur eine .htaccess und nicht hundert...mal guggn.

Quote from: Medizinmann99 on September 01, 2006, 07:49:08 AM
Auf die Schnelle finde ich nur eine .htaccess und zwar im Unterordner Attachments.

du musst eine neue .htaccess anlegen wenn es noch keine in dem Verzeichnis, in dem die Settings.php liegt, gibt.

@Rest: Du musst natürlich nicht die komplette Datenbank exportieren, sondern nur den Inhalt, die Tabellen.

Dazu gehst du in phpmyadmin, wählst die Datenbank aus, gehst dort auf exportieren und dann wählst du alle Tabellen aus.

edit: War wohl einer schneller ;)

Medizinmann99

Hm ich stelle jetzt die .htaccess im Ordner Attachments wieder in den Originalzustand
dann kopiere ich die raus aufs hauptverzeichnis und trage nur das ein was Ihr mir gesagt habt und sehe nach was dann passiert :-)

die sache mit den tabellen in phpmyadmin ist mir vorerst schleierhaft komme später dazu erst versuche ich das obige

Medizinmann99

so es gibt jetzt eine neue .htaccess datei im hauptverzeichnis des forums da wo die settings.php auch ist

sie hat als einziges folgenden inhalt:

<IfModule mod_security.c>
   # Turn off mod_security filtering.  SMF is a big boy, it doesn't need its hands held.
   SecFilterEngine Off

   # The below probably isn't needed, but better safe than sorry.
   SecFilterScanPOST Off
</IfModule>

das ist ihm völlig wurscht, das magische wort prescription mag er einfach nicht

jetzt wende ich mich dieser tabellengeschichte zu

Medizinmann99

#44
ok ich habs jetzt mit mysqldumper versucht weil völlig egal was man mit myphpadmin macht es kommt ohnehin immer eine fehlermeldung. Sicherlich würde es irgendwann gehen wenn ich mir jetzt ein paar Stunden ZEit nehmen würde damit rumzuspielen aber danke, ich bin nicht so der Programmierertyp. In den Foren sind Anleitungen um einzelne MySQL Fehler zu beheben immer EXTREM stichwortartig, damit kann man nicht arbeiten.

also habe ich jetzt mysqldumper ORDNUNGSGEMÄSS (ohne fehlermeldung) bei ohost.de installiert
die ohost.de datenbank mit mysqldumper exportiert in eine gzip datei

dann mysqldumper ORDNUNGSGEMÄSS (ohne fehlermeldung) bei pytal.de installiert
die ohost.de datenbank importiert mit mysqldumper aus der eben erstellen gzip datei

alle forendaten 1:1 von ohost.de mittels ftp auf meine festplatte übertragen
alle forendaten 1:1 von der festplatte nach www.pytal.de übertragen

repair_settings.php ausgeführt

Das Ergebnis ist hier:
http://meulengracht.pytalhost.com/index.php

Wie ihr im Vergleich zu
www.meulengracht.de.vu
sehen könnt, gibt es einige Sonderbarkeiten (die schwarzen Balken, obwohl die Themes Verzeichnisse 1:1 ident sind) und dergleichen. Die ganze Optik ist völlig anders.

Die Datenbank ist aber wohl richtig importiert, weil alles da ist.

Nur die Optik ist im Classic Yabb SE Theme völlig anders.

Gähn. Hat dafür irgendjemand eine Erklärung? Jetzt wirds echt langsam langweilig hier.

xduugu

Ich bezweifel fast, dass die Dateien wirklich zu 100% gleich sind...

Medizinmann99

#46
Ich spiele jetzt noch ein bißchen damit herum. Als FTP Client verwende ich Filezilla. ICh hoffe das dumme Ding macht was man ihm sagt (weil bei FTP Clients ist das ja meistens nicht sicher).

D.h. ich mach jetzt nochmal die 1:1 Kopie der Dateien von Ohost.de auf meine Festplatte und dann wieder einen frischen Upload all dieser Dateien nach Pytal.de

Medizinmann99

Ich installiere jetzt dort ein Standardforum 1.1. RC3 und schreibe mir erst mal alle Pfade raus. Inklusive dieser komischen Themespfade. Ich glaube die Repairphp stellt irgendwie die Themes-Pfade nicht richtig? Naja das versuch ich jetzt mal.

Medizinmann99

Hm mir sind diese ganzen FTP PRogramme die ich bis jetzt versuchte inzwischen äußerst suspekt (Erklärungen erspare ich mir). Ich bin mir bei diesem Schrott nie sicher daß das auch macht, was ich sage daß es machen soll. Weiß jemand ein gutes FTP Programm, das auch wirklich das macht, was man ihm sagt?

Als ich das erste Mal ein Forum transferierte verwendete ich noch ein Profiprogramm innerhalb der Evaluationsdauer. Dieses Programm funktionierte perfekt.

Jetzt ist das aber abgelaufen also muß ich das Freeware Zeug verwenden. Im Moment verwende ich Filezilla.

Kennt jemand ein zuverlässige(re)s FTP Programm? :-)

Medizinmann99

Soderla ich hab jetzt noch mal das Gleiche gemacht. Jetzt kann vom Forum keine Verbindung zur SQL Datenbank hergestellt werden, komischerweise, ganz wurscht was ich mache. Die Datenbank wurde auf alle Fälle korrekt hochgeladen und ist bereits auf dem pytal.de Server. Dasselbe habe ich ja vorhin beim ersten Versuch auch gemacht und da gings. LOL liegt wohl am Freehoster, wahrscheinlich abgekackt, deswegen gehts im Moment nicht. Nehme ich stark an...ich probiers später wieder... :-)

Medizinmann99

Geschafft! :-) Ihr könnt den Thread als gelöst markieren.

Den Rest könnt ihr hier nachlesen, warum und weshalb:
http://www.pytal.de/topic,8,0,3388,999

Aus meiner kleinen Odyssee ließen (lassen) sich aber EINIGE Konsequenzen ziehen bzw. könntet ihr versuchen das irgendwie zu verwerten.

Und zwar...Sicherungen mit SMF zu erstellen macht wohl nur wenig Sinn, da man sie ohnehin nicht gescheit importieren kann ohne ein SQL Experte zu sein (Fehlerstakkato daß es nur so rauscht).
Mit PHPMyadmin gehts auch nur wenn man sich genau auskennt mit den Kommandos. Soweit bin ich noch nicht. Das Hauptproblem ist immer dasselbe, er versucht eine Datenbank zu createn aber es existiert bereits eine. Löscht man den Create Befehl raus, kommt bei vielen (nicht allen) Hostern die nächste Fehlermeldung. Und so weiter und so fort. Das ist echt heftig.

Mit MySQLDumper ists aber babyeinfach. D.h. ich würde sagen am ratsamsten und fehlerfreiesten geht es sowohl die Sicherungen mit MySQLDumper zu machen als auch im Fehlerfall mit MySQLDumper den Upload zu machen .

Wohlgemerkt die BESTE Möglichkeit wäre, wenn die SMF Forensoftware ebenso wie sie die SICHERUNG erstellt auch direkt unter Administration Wartung die Wiederherstellung machen könnte. Natürlich macht das nur Sinn, wenn das Forum noch einigermaßen intakt ist, zugegebenermaßen. Man könnte es auch so machen daß eine WIederherstellung innerhalb des Forums geht über Administration oder aber mit einer eigenen Skriptdatei, z. Bsp. restore_smfdatabase.php oder sowas. Wo man einfach die SMF Forensicherung per FTP auf den Server überträgt zusammen mit so einer restore_smfdatabase.php und die dann ausführt. Das wäre optimal und am benutzerfreundlichsten.

Der eigentliche Grund übrigens für die optische Abweichung war, weil die repair_settings.php die THEMES PFADE NICHT WIEDERHERSTELLT.

D.h. es stehen immer noch die Themes Pfade des alten Forums dort. Und übrigens ich habe bis heute nicht herausgefunden wie ich diese absurden Themes Pfade jemals auf einem neuen Server herausfinden soll.

Deswegen habe ich es bis jetzt immer so gemacht ich installiere extra ein neues SMF Standardforum stelle auf das gewünschte Theme um und schreibe mir dann die Pfade raus. Dummerweise habe ich das diesmal vergessen weil ich vergaß daß die Repair_settings.php das eben NICHT macht.

Das Problem ist ihr weist NIRGENDWO darauf hin daß die Repair_settings.php das NICHT macht, daß also die Themes Pfade völlig falsch sind. Auch wenn die Dateien 1:1 übertragen wurden, das nützt dann ja nichts.

Das ist also "strenggenommen" Euer Fehler darauf nicht hinzuweisen denn diese Information ist ja wohl höchst wichtig. Schließlich soll das Forum auch wieder den alten optischen Look bekommen! :-)

Auf alle Fälle geht jetzt alles und ich habe wieder ein bißchen was gelernt.

Beim MySQLDumper steht unten im Menü übrigens noch "Verzeichnisschutz erstellen". Ich vermute das dient dazu das /mysqldumper Verzeichnis zu schützen daß nicht irgendwer dort einfach einsteigen und die Datenbank manipulieren kann, ist das richtig? Sollte man das machen? Kann es da dann irgendwelche Komplikationen geben?

Danke xduugu für Dein hilfreiches Angebot für mich dort reinzuguggn was verkehrt war heute, das ist sehr nett von Dir.

noex

Quote from: Medizinmann99 on September 01, 2006, 06:06:51 PM
Der eigentliche Grund übrigens für die optische Abweichung war, weil die repair_settings.php die THEMES PFADE NICHT WIEDERHERSTELLT.
Das stimmt so nicht ganz.
Siehe: http://www.simplemachines.org/community/index.php?topic=55527.0

Quote
6. Wenn du mehrere Themes installiert hast, beachte bitte dass du auch in den Theme Einstellungen die Pfade der einzelnen Themes noch anpassen musst.

Ich werde die Formulierung noch ändern damit eindeutig daraus hervorgeht das nur das default Theme korrigiert wird.
"Jetzt, wo ich weiß wie es geht, versteh ich auch die Gebrauchsanleitung"

Medizinmann99

#52
Hallo,

das Problem das ich hatte ich wußte die Themes Pfade einfach nicht. Ich meine natürlich wußte ich den "Internet Pfad", und natürlich wußte ich den "internen Pfad" ab der Stelle wo ich das im FTP Programm sehen kann. Das ist aber nicht der wirkliche, absolute Pfad. Die Repair_settings.php ermittelt diesen absoluten Pfad (oder was immer das ist) ja irgendwie.

Und ich habe keine Ahnung wie :-) INsoferne habe ich auch keine Ahnung wie man so einen Pfad ermitteln soll. Ich kann den nicht eintragen, wenn ich ihn nicht weiß, selbst wenn ich darauf hingewiesen werde daß ich das tun muß.

Ich denke um das zu ermitteln man muß sich die Pfade ansehen die die REpair_settings.php erstellt hat und auf dieser Basis dann versuchen den richtigen Themenpfade zu ermitteln (den also auf dieser Basis abzuwandeln sozusagen). Nur habe ich das das letzte Mal nicht geschafft (ich habe es aber auch nicht besonders lange versucht).

Deswegen habe ich eben das SMF Standardforum installiert, auf meinen Theme umgestellt und mir die Pfade rausgeschrieben, die der Foreninstaller ermittelt hat und dann erst meine ganzen Daten übertragen und Datenbank eingespielt und dann die so ermittelten Pfade dort rein geschrieben. Wenn der Foreninstaller übrigens dieses Verzeichnis ermitteln kann müßte es irgendwie möglich sein diese Funktion noch in die Repair_settings.php zu übertragen, daß auch diese Pfade modifiziert werden, denke ich.

Außerdem war ein weiteres Hauptproblem daß in der ohost.de Datenbank alle Tabellenpräfixe bei mir smf_ irgendwas waren, bzw. im Backup davon backup_smf (<-- warum das Wort "Backup" davor hinzu kam weiß ich nicht, vermutlich hat das mysqldumper so verändert, weil es eben ein Backup ist oder so?) und bei meinem Zielhost offenbar alles mit phostXXXX beginnen muß. Zumindestens erinnere ich mich bei der Installation vom SMF Standardforum nahm er SMF_ gar nicht an (was auch beim Wiedereinspielen dann nicht funktioniert hätte wegen der backup_smf Geschichte, aber das ist wohl eine Spezialität von mysqldumper), er nahm nur phostXXXX_ an. Das mußte ich manuell verändern, d.h. mit Suchen und ersetzen. Erst dann gings. Ich brauchte dazu übrigens auch noch ein Extraprogramm, da Mysqldumper nur GZIP und nicht ZIP annimmt. ZUnächst versuchte ich es mit dem Download eines GZIP Utilities, das unter DOS auf KOMMANDOZEILENEBENE mit den steinzeitlichen Schaltern ablief (und bei mir lagen diese ganzen Dateien tief unten in der Verzeichnisebene, 8 Zeichen-Verzeichnisbegrenzung...)...weil Winzip der Mist kann ja kein GZIP machen.

Gott sei dank fand ich dann heraus, daß man GZIPs mit dem Packprogramm 7zip, das auf einer zeitgemäßen Oberfläche läuft und das in das Kontextmenü das daherkommt wenn man am Desktop oder im Arbeitsplatz irgendwo rechtsklickt integriert ist, auch erstellen kann.

Jemand der das nicht wußte der hätte dann erst mal stundenlang versuchen müssen irgendwie so ein GZIP zu erstellen, und das mit diesem Steinzeit GZIP Programm ggf..
(übrigens ein bestehendes GZIP zu öffnen, die darin enthaltene Datei zu löschen und die neue Datei dorthinzuziehen geht NICHT, da spielt Winzip nicht mit, versucht das mal)

Es können da also schon reichlich Dinge auftreten, die so nirgendwo erwähnt werden. Diese ganzen Datenbanktransferanleitungen sind in meinen Augen reichlich dürftig, die sind viel zu stichwortartig. Im Prinzip stimmt natürlich aber alles was da steht...

Es müßte einfach mal eine "narrensichere" Anleitung geschrieben werden und diese STICKY in alle Foren wo einer danach suchen könnte angebracht werden. Also ich denke narrensicher wäre die MySQLDumper Methode aber dann solltet ihr auch noch eine kleine Anleitung zu MySQLDumper erstellen. Auf die möglichen Präfix Probleme müßtet ihr hinweisen und wie man die Themes Pfade manuell ermittelt, möglichst mit Beispielen. Dazu erklären wie man ein Gzip erstellt mit 7zip kurz etc. etc. etc..

Ich z. Bsp. habe längere Zeit (das ist aber schon länger her) übrigens nicht kapiert, daß ich wenn ich die Repair_settings.php ausführe jeweils EINZELN auf die blauen Links klicken muß, damit sich das ändert. Ich bin ganz am Anfang immer nur unten auf Speichern gegangen und habe mich gewundert, daß es nicht funktioniert, lol! :-DDDDD

Alles, was nicht narrensicher ist, wird irgendwann falsch bedient, ich meine bei Foren ists ja nicht so schlimm, aber wegen solcher Kleinigkeiten explodieren Ölplattformen, stürzen Flugzeuge ab oder haben wir im Moment die zweite Weltwirtschaftskrise (das liegt auch an so einer "Kleinigkeit").

"Liegt der Irrtum erst wie ein Grundstein am Boden, nieeeeeee meeeeeeeeeeeehr (mit Gruftistimme!) kommt er ans Tageslicht!!!!!"

:-DDDDD

Ayko

Vielleicht hättest du einfach mal den BBC-Code checken sollen und das pre deaktivieren.

Nur so eine Idee.

Medizinmann99

Hallo,

danke für die späte Antwort, aber daran lags nicht. Hab das selbstredend auch versucht.

Das Problem war ja so irre, daß ich es heute noch kaum glauben kann, daß es wirklich passiert ist. Erfolg brachte der Wechsel zu einem anderen Hoster. Ob diese Wortsperrengeschichte bei Ohost immer noch drin ist weiß ich nicht.

Liebe Grüße

Medizinmann99

Advertisement: