Nur Leserechte settings.php - Deaktivieren?
![](http://www.drupalcenter.de/files/noavatar_mini.gif)
am 09.03.2009 - 17:48 Uhr in
Hi,
ich finde es ziemlich lästig, dass Drupal die settings.php permanent in den read-only Modus "changemodet".
Kann man das ohne Corehackerei deaktivieren?
- Anmelden oder Registrieren um Kommentare zu schreiben
Sicherheitsfunktion
am 09.03.2009 - 17:56 Uhr
Hallo,
das ist eine Sicherheitsfunktion. Warum willst du nach der Installation in die Datei schreiben?
Gruß
Frank
Während der
am 09.03.2009 - 18:04 Uhr
Ich kenne den Hintergrund ;=)
Während der Entwicklungsphase eines Projektes ändern sich bestimmte Dinge häufiger und mein Subversion ist ständig am Abnerven, da es im default-Ordner nix schreiben darf. Ausserdem hantiere ich permanent mit 2 Stadien eines Projektes, einmal online und einmal offline - es ist einfach nur lästig.
Ich möchte gerne selber entscheiden, wann ich bestimmte Dateien/Ordner chmode.
Gibt es da was?
Schreibschutz für settings.php aufheben
am 09.03.2009 - 18:15 Uhr
Aha, das klingt plausibel ;-)
Guck doch mal, ob du hier was Passendes findest:
http://drupal.org/search/apachesolr_search/settings.php+write+protected
Und wenn du weißt, was du machst, kannst du auch hier mal nachlesen:
Wie kann ich auf transparente Weise Funktionen von Kernmodulen überschreiben?
http://www.drupalcenter.de/faq/15087
hdh
Frank
Jo, danke schön, das ist
am 09.03.2009 - 18:17 Uhr
Jo, danke schön, das ist doch mal ein Ansatz!
Da werde ich sicher etwas finden :)
Multisite-Installation: eine Codebasis - mehrere Datenbanken
am 09.03.2009 - 22:02 Uhr
Hast du schon mal überlegt, ob eine Multitsite-Installation nicht eine Alternative wäre? In der settings.php ist doch eigentlich nur die Datenbank sinnvoll zu ändern, oder? Mit einer Multisite-Installation kannst du wesentlich eleganter mit unterschiedlichen Konfigurationen arbeiten.
Eine Multisite-Installation auf dem eigenen Rechner
http://www.drupalcenter.de/handbuch/6083
Gruß
Frank
Ich bin gerade dabei, eine
am 09.03.2009 - 22:56 Uhr
Ich bin gerade dabei, eine Seite mit dem Domain Access Module aufzubauen. Das ist ja ähnlich, bis auf das alles aus einer DB/Konfig kommt. Allerdings schmeiss ich den Mist bald hin, da Drupal bzw. die Module teilweise einfach nicht richtig funktionieren.
So passiert z. B. im Moment auf meiner Seite beim Permission rebuilden gar nichts Ich lese zwar, dass Drupal sich vorgenommen hat, die Rechte neu zu erstellen, aber der Balken/Reload bleibt aus und die node_access Tabelle ist danach leer. Vor 3 Tagen hat alles noch super funktioniert?!
Macht sich super mit 30 Einzelseiten, die fix und fertig angelegt worden sind. Wäre mir das mit einer Produktivumgebung passiert - Gute Nacht. Warum Gute Nacht? Mein wieder eingespielter DB Dump hat veränderte Primärschlüssel, weil irgendwas mit dem auto_increment Wert nicht hinhaut.
Warum das Problem auftritt, kann ich nicht sagen. Man kann zwar rumsuchen und -lesen, allerdings ist das wenig zielführend, da die evtl. Lösungen im Chaos und unter Patches vergraben sind.
Ich muss leider sagen, dass mich diese Dinge ziemlich frustrieren. Ich habe professionelle Erfahrung mit 4-5 CM Systemen und hatte mich eigentlich auf Drupal gefreut bzw. Gutes gehört.
Aber ich finde es teilweise unberechenbar, auf Codeebene wenig transparent und ziemlich umständlich. Wenn ich mir den Aufbau eines Themes aus Designersicht ansehen - ohje, auf die Einarbeitung freut man sich nicht.
Und man mag mir nicht vorwerfen, nicht ausdauernd genug zu sein - ich habe mittlerweile ca. 30-35 reine Arbeitsstunden mit Drupal und den Communityseiten verbracht.
EDITh sagt noch: Das http request Problem im Statusbericht hatte/habe ich heute auch noch.
So, Kommando zurück: Es ist
am 10.03.2009 - 00:45 Uhr
So, Kommando zurück: Es ist unglaublich, aber entweder kommt Drupal bzw. Domain Access oder der MAMP nicht mit Strichen in Sub-Domainnamen/Hostnamen zurecht.
testinstall.domain.tld <- funktioniert
test-install.domain.tld <- funktioniert nicht richtig
Na da habe ich doch heute 'nen richtig runden Tag wegen so einer Shi*e gehabt :/