Achtung: Symikolon hinter array_fill_keys( $aRequiredPHPConfigs, ‘php_config’ ) setzen
Einfach die .htaccess Datei weglassen brachte nur die Meldung. mod_rewrite nicht konfiguriert. (geladen ist das Modul)
Mit .htaccess Datei und ohne Codeausklammerung gibt’s bei mir einen Server error.
Mit .htaccess Datei und Codeausklammerung funktioniert es, solange der Code ausgeklammert bleibt.
Keine elegante Methode, ich weiss, aber anders ging’s nicht.
auch ich kann den Fehler nachvollziehen
PHP läuft als Apache Modul
mod_rewrite ist geladen und funktioniert problemlos!
Oxid behauptet aber das Gegenteil
Es kann sich gerne ein Mod für ein Testzugang bei mir melden
Das Problem ist jetzt schon mehrere Monate alt und kein Aushängeschild
für diesen Shop
Wer sicher ist das mod_rewrite funktioniert trotz dessen das Oxid das Gegenteil behauptet
Editiert einfach die Datei oxsysrequirements.php im Verzeichnis core
und ersetzt die Zeile 205 von return $iModStat; in
$iModStat = 2;return $iModStat;
[QUOTE=kathrin-77;7340]Ich hatte vor ein paar Tagen das gleiche Problem. Ursache bei mir war, dass ich in der Original htaccess noch 3 Zeilen für einen Verzeichnisschutz reingeschrieben habe. Dann stand bei der Installation bei mir komischerweise auch, dass mod_rewrite nicht funktioniert, was ja definitiv nicht stimmte. Also habe ich ohne Verzeichnisschutz installiert und dann wieder (für die Entwicklungszeit) einen Verzeichnisschutz reingebaut. Im Shop wird im Backend zwar nun wieder angezeigt, dass mod_rewrite nicht funktioniert, aber dem ist nicht so, alles funktioniert richtig.
Vielleicht hast du ein ähnlich “einfaches” Problem?
nein - bitte nicht in der Zeile 138 der oxsysrequirements.php. Gehen Sie bitte in die Zeile 393.
In der function checkModRewrite() -> Zeile 393 kann man -> [B][U]return 1[/U][/B]; eingeben, wenn
in der phpInfo das mod_rewrite erkannt wurde. Dann wird der Status auf “orange” gesetzt und
die Installation funktioniert vollständig.
Das Problem gibt es im Apache 2.2 in der nicht offiziellen x64 Version. Dort wird mod_rewrite
zwar erkannt, erzeugt aber im Apachex64 einen bisher unbehobenen Bug.
Das Problem gibt es im Apache 2.2 in der nicht offiziellen x64 Version. Dort wird mod_rewrite
zwar erkannt, erzeugt aber im Apachex64 einen bisher unbehobenen Bug.
Echt? Wie soll man denn auf so etwas kommen? Danke für den Hinweis!
ich habe seit neuestem auch dasselbe Problem, nachdem mein Hoster alles auf 64 BIT umgestellt hast, sagt die Systemgesundheit, dass das Apache mo_rewrite Modul faul ist, ist es aber nicht
wird das Verzeichnis virtuell eingebunden, so bietet es sich an, Rewrite gleich in der .conf abzulegen. Der Knackpunkt ist hier, dass anstelle von RewriteBase alles in eine <Location> zu packen ist:
Alias /oxid /home/oxid/www
<Directory /home/oxid/www>
Options Indexes FollowSymLinks
<IfModule mod_php5.c>
php_flag register_globals off
</IfModule>
<IfModule mod_dir.c>
DirectoryIndex index.php
</IfModule>
# access to configtest is limited by default to prevent information leak
# <Files configtest.php>
# order deny,allow
# deny from all
# allow from 127.0.0.1
# </Files>
</Directory>
# users will prefer a simple URL like http://webmail.example.com
#<VirtualHost 1.2.3.4>
# DocumentRoot /usr/share/squirrelmail
# ServerName webmail.example.com
#</VirtualHost>
# redirect to https when available (thanks [email protected])
# Note: There are multiple ways to do this, and which one is suitable for
# your site's configuration depends. Consult the apache documentation if
# you're unsure, as this example might not work everywhere.
#
<IfModule mod_rewrite.c>
Options +FollowSymLinks
<Location /oxid>
RewriteEngine On
RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK)
RewriteRule .* - [F]
RewriteCond %{REQUEST_URI} oxseo\.php$
RewriteCond %{QUERY_STRING} mod_rewrite_module_is=off
RewriteRule oxseo\.php$ oxseo.php?mod_rewrite_module_is=on [L]
RewriteCond %{REQUEST_URI} !(\/admin\/|\/core\/|\/export\/|\/modules\/|\/out\/|\/setup\/|\/tmp\/|\/views\/)
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule !(\.html|\/|\.jpg|\.css|\.pdf|\.doc|\.gif|\.png|\.js|\.htc)$ %{REQUEST_URI}/ [R=301,L]
RewriteCond %{REQUEST_URI} !(\/admin\/|\/core\/|\/export\/|\/modules\/|\/out\/|\/setup\/|\/tmp\/|\/views\/)
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule (\.html|\/)$ oxseo.php
RewriteCond %{REQUEST_URI} (\/out\/pictures\/)
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule (\.jpg|\.gif|\.png)$ core/utils/getimg.php
</Location>
# <IfModule mod_ssl.c>
# <Location /oxid>
# RewriteEngine on
# RewriteCond %{HTTPS} !^on$ [NC]
# RewriteRule . https://%{HTTP_HOST}%{REQUEST_URI} [L]
# </Location>
# </IfModule>
</IfModule>
das Problemchen mit dem Verzeichnisschutz hat mir auch soeben eine Stunde gekostet. Der Bugreport aus 2009 zeigt dass das Problem wohl schon länger existiert - wäre schön wenn das gelöst werden würde. Zumindest ein Hinweis (Verzeichnisschutz ggf. abschalten) im Wiki zur Fehlermeldung wäre ein Hit
[QUOTE=attec;72511]Zumindest ein Hinweis (Verzeichnisschutz ggf. abschalten) im Wiki zur Fehlermeldung wäre ein Hit :)[/QUOTE]
Diesen sehr einfach umzusetzenden Vorschlag habe ich 2009 ebenfalls gemacht. Allerdings sollte der Hinweis auf der Installationsseite stehen - ins Wiki schaut man in dem Moment bestimmt nicht.
Leider war mein Vorschlag vergeblich. :mad:
Willkommen im Club derer, die das unnötig zusätzliche Zeit gekostet hat.
Ist resolved markiert, ist aber offensichtlich noch immer aktuell.
@DSB
Stimmt, direkt ins Setup reinschreiben wäre noch unkomplizierter. Noch besser wäre natürlich wenn der rewrite check trotz Verzeichnisschutz funktioniert und nicht fälschlich als Fehler erkannt wird. Eine Installation wird dadurch unmöglich und führt vorm ersten Hands-on schon zum Frust
Hast Du Dir das mal durchgelesen?
Angeblich ist das seit Version 4.3.0 “gelöst”. Ist es aber nicht. Demjenigen, der dasTicket auf resolved gesetzt hat, gehören die Finger abgehackt.
Ich habe die technische Erklärung im Bugtracker noch einmal als Note angefügt, so dass niemand mehr lange suchen muss.
Spasseshalber habe ich mir das SVN-Log von oxsysrequirements.php einmal angesehen. Zumindest an der Funktion checkModRewrite() wurde nichts geändert. Ob einmal eine Textausgabe auf dem Installationsscreen vorhanden war, habe ich nicht mehr geprüft. Die nichtssagenden Log-Messages (nightly build…) haben mich davon abgehalten.
Ich habe auf einem Windows 8.1/64 Rechner das aktuelle XAMP.Paket1.8.3 mit Joomla via BitNami. Den Shop habe ich also lokal in einem Ordner unterhalb von Joomla “shop” entpackt. Beim Aufruf ist alles in “grün” - ausser das Appache Mod_rewrite. Das habe ich auf FileInfo oder auf All gestellt - an allen Stellen, die ich in der Konfigdatei finden konnte. Appache neu gestartet keine Änderung.
Auch die hier gefundene Möglichkeit die oxsysrequirements.php anzupassen wollte ich verfolgen.
Jedoch finde ich in Zeile 393 : $iPort = $blSsl?443:80;
Ja, eine “.htaccess”-Datei ist vorhanden, einmal im “shop”-Ordner und auch im Ordner für die Joomla-Installation. In beiden habe ich die Änderung gemacht, bzw ich habe die Aktion “Konfig” des XAMP-Kontrol-Fensters benutzt. Diese ruft die Appache-Conf in einem Editor auf, in dem ich dann nach “allow” gesucht habe.
Ich habe die 4.10.1 er Version versucht zu installieren, gleiches Problem wie wohl schon seit Jahren ?
mod_rewrite funktioniert einwandfrei auf dem 1&1 Host.
Andere Systeme auf dem Host laufen auch mit mod_rewrite.
Ich habe das Thema hier gelesen, nur passt von den Vorschlägen wohl nichts auf meine Version.
Wäre es zu viel verlangt, ganz einfach zu erklären, ob und wie der Fehler behoben werden kann?
Mir ist schon klar, dass diese Version kostenlos ist, es gibt aber sehr viele andere kostenlose Produkte, die recht gut laufen.
Erweiterungen kosten ja auch in dieser Version Geld, also warum will man diesen Fehler nicht ganz schlicht und einfach beheben und den Kunden somit Ärger und viel Sucherei ersparen?
Auf diese Art kaufen wir niemals eine kostenpflichtige Version, wenn es hier schon scheinbar keine Fehlerbehebung gibt, man bedenke mal ganz ganz einfach, wann dieses Thema eröffnet wurde …, ist das normal?
Würde mich über eine kurze hilfreiche Lösungsehr freuen …
Der Workaround wurde in en ersten Posts dieses Threads mehrfach beschrieben:
Während der Installation den Verzeichnisschutz auf das Shopverzeichnis entfernen. Dann sollte die Installation durchlaufen. Danach kann der Verzeichnischutz wieder aktiviert werden.
