Community Edition & IIS

Ja läuft bei mir mit IIS Version 6. Und nur die Fullversion von Helicon. Die config von Oxid muss natürlich mit jedem Slash usw. haargenau passen und in die index von Oxid muss das rein
if (isset($_SERVER[‘HTTP_X_REWRITE_URL’]))
{
$_SERVER[‘REQUEST_URI’] = $_SERVER[‘HTTP_X_REWRITE_URL’];
}

Die Rechte über dem Host müssen passen.
Hier noch die Testdomain
http://oxyd.net-te.ch
und die Rules

<IfModule mod_rewrite.c>
AddDefaultCharset UTF8
#Options +FollowSymLinks
RewriteEngine On
RewriteCond %{REQUEST_URI} !(/core/|/export/|/modules/|/out/|/setup/|/tmp/|/views/)
RewriteRule admin/test.php$ admin/test.php?mod_rewrite=1
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)$ %{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
</IfModule>

disabling log file access from outside

<FilesMatch “(EXCEPTION_LOG.txt|.log$|.tpl$)”>
order allow,deny
deny from all
</FilesMatch>
Options -Indexes

Für weiter Gespräche müssten natürlich weitere Angaben geschildert werden. Was läuft den sonst noch so alles auf den Kisten?
Gruss

[QUOTE=medea;18513]Nein, keine Sorge, die hab ich schon angepasst, zumindest die Einstellungen für die Datenbank (/** @name database information */). Startseite und Adminbereich funktionieren auch, nur wenn ich auf einen Link klicke kommt die Umleitungsfehlermeldung.

Hab inzwischen auch die Vollversion von Helicon installiert, selbes Ergebnis, aber das error.log file ist etwas mitteilsamer. Nach einem Klick auf “Geschenke” steht dort folgendes:

[13.11.2009 12:45:01] C:\Programme\Helicon\ISAPI_Rewrite3\httpd.conf - Loaded successfully
[13.11.2009 12:45:01] ISAPI Filter loaded. Version 3.1.0.67. Windows 5.0 (Build 2195 ServicePack:4) ProductType SERVER. CPU type INTEL NumberOfProcessors 1.
[13.11.2009 12:45:15] Unknown expression in the file c:\inetpub\wwwroot\oxid.htaccess, on the line #1: Options +FollowSymLinks
[13.11.2009 12:45:15] Unknown expression in the file c:\inetpub\wwwroot\oxid.htaccess, on the line #20: Options -Indexes
[13.11.2009 12:45:15] c:\inetpub\wwwroot\oxid.htaccess - Loaded successfully
[13.11.2009 12:45:15] Unknown expression in the file c:\inetpub\wwwroot\oxid.htaccess, on the line #1: Options +FollowSymLinks
[13.11.2009 12:45:15] Unknown expression in the file c:\inetpub\wwwroot\oxid.htaccess, on the line #20: Options -Indexes
[13.11.2009 12:45:15] c:\inetpub\wwwroot\oxid.htaccess - Loaded successfully

Scheint ein Problem mit den Optionen +FollowSymLinks und -Indexes zu haben. Auch das interaktive Konfiguratiosprogramm von Helicon motzt über die beiden Zeilen:

Unknown expression on line #1: Options +FollowSymLinks
Unknown expression on line #20: Options -Indexes"

Hab gestern auch den freien mod_rewrite IIRF.dll von Ionic Shade getestet. Aktivierung kein Problem, er motzte aber auch über die beiden Zeilen.
Sind die nicht kompatibel zu den IIS-rewritern ?
Wozu braucht es die ?

Wenn ich sie lösche wird offensichtlich ein rewrite durchgeführt, denn ich bekomme Meldungen im Helicon log-file “rewrite.log”, das vorher nie angelegt wurde.

Dort stehen dann jede Menge Zeilen der folgenden Art drin, vielleicht sagen die jemandem mehr als mir, sind schließlich meine ersten Schritte mit diesen Dingen…:

192.168.1.10 192.168.1.10 Fri, 13-Nov-2009 12:53:47 GMT [www.<mein-shop>.de/sid#3][rid#13221992/initial] (2) init rewrite engine with requested uri /oxseo.php
192.168.1.10 192.168.1.10 Fri, 13-Nov-2009 12:53:47 GMT [www.<mein-shop>.de/sid#3][rid#13221992/initial] (1) Htaccess process request C:\Programme\Helicon\ISAPI_Rewrite3\httpd.conf
192.168.1.10 192.168.1.10 Fri, 13-Nov-2009 12:53:47 GMT [www.<mein-shop>.de/sid#3][rid#13221992/initial] (1) Htaccess process request c:\inetpub\wwwroot\oxid.htaccess
192.168.1.10 192.168.1.10 Fri, 13-Nov-2009 12:53:47 GMT [www.<mein-shop>.de/sid#3][rid#13221992/initial] (3) applying pattern ‘admin/test.php$’ to uri ‘oxseo.php’
192.168.1.10 192.168.1.10 Fri, 13-Nov-2009 12:53:47 GMT [www.<mein-shop>.de/sid#3][rid#13221992/initial] (3) applying pattern ‘(.html|/|.jpg|.css|.pdf|.doc|.gif|.png|.js)$’ to uri ‘oxseo.php’
192.168.1.10 192.168.1.10 Fri, 13-Nov-2009 12:53:47 GMT [www.<mein-shop>.desid#3][rid#13221992/initial] (4) RewriteCond: input=’/oxseo.php’ pattern=’(/admin/|/core/|/export/|/modules/|/out/|/setup/|/tmp/|/views/)’ => matched
192.168.1.10 192.168.1.10 Fri, 13-Nov-2009 12:53:47 GMT [www.<mein-shop>.de/sid#3][rid#13221992/initial] (4) RewriteCond: input=’’ pattern=’!-f’ => matched
192.168.1.10 192.168.1.10 Fri, 13-Nov-2009 12:53:47 GMT [www.<mein-shop>.de/sid#3][rid#13221992/initial] (4) RewriteCond: input=’’ pattern=’!-d’ => matched
192.168.1.10 192.168.1.10 Fri, 13-Nov-2009 12:53:47 GMT [www.<mein-shop>.de/sid#3][rid#13221992/initial] (1) escaping /oxseo.php/
192.168.1.10 192.168.1.10 Fri, 13-Nov-2009 12:53:47 GMT [www.<mein-shop>.de/sid#3][rid#13221992/initial] (2) explicitly forcing redirect with http://www.<mein-shop>.de/oxseo.php/
192.168.1.10 192.168.1.10 Fri, 13-Nov-2009 12:53:47 GMT [www.<mein-shop>.de/sid#3][rid#13221992/initial] (2) internal redirect with /oxseo.php [INTERNAL REDIRECT]

Herzlichen Dank für jede Hilfe.
Andreas[/QUOTE]

Da stimmt die config nicht…

jo da stehen in sShopDir und sShopUrl noch die default werte drin.

Noch zu erwähnen ist, dass die # (Route) von Helicon als Fehler zurückgegeben wird. Kennt scheinbar dieses Zeichen nicht. Diese Auskommentierung wird nicht erkannt als Rule, ist ja auch keine…

[QUOTE=roland76;19069]Interessant wäre noch zu wissen, ob pctechnikch das Script ebenfalls auf einem IIS5 oder bereits auf IIS6 oder sogar 7 zum Laufen gebracht hat.
Um zukünfigten Problemen aus dem Weg zu gehen, würde ich den Shop aber trotzdem auf einem Apache betreiben.[/QUOTE]

Hi,
danke für den Tip, aber ich denke das Problem ist nicht der IIS, sondern das rewriting. Also für mich als langgedienten Entwickler sind daran 3 Komponenten beteiligt:
die .htaccess Datei, die mod_rewrite engine von Helicon und natürlich der PHP-Quellcode von OXID. Irgendwie stimmt das Zusammenspiel hier nicht…

[QUOTE=csimon;19115]jo da stehen in sShopDir und sShopUrl noch die default werte drin.[/QUOTE]

Die ist schon ok, hab nur im posting meine domain durch <mein-shop> ersetzt…

Danke
Andreas

[QUOTE=pctechnikch;19096]Da stimmt die config nicht…[/QUOTE]
Was genau könnte da fehlen ?
Möchte darauf hinweisen, dass im Logfile von Helicon immer wieder die Zeile mit "escaping /oxseo.php/ " vorkommt, schein mir ein Abbruch zu sein, der eine Endlosschleife verhindern soll. Die Fehlermeldung im Browser heisst ja auch “Fehler: Umleitungsfehler: Die aufgerufene Website leitet die Anfrage so um, dass sie nie beendet werden kann.”

Kontrolliere doch…

[ul]
[li]index.php modifiziert, bzw. ergänzt wie angegeben… mit den Slashes!!![/li][/ul]
[ul]
[li]stimmt die oxyd config wirklich[/li][/ul]
[ul]
[li]passt die .htaccess wie angegeben[/li][/ul]
[ul]
[li]ist die Registerkarte von Helicon vorhanden unter iis[/li][/ul]
[ul]
[li]sind die Rechte richtig gesetzt über der .htaccess und dem Host[/li][/ul]
[ul]
[li]Webdiensterweiterungen, erforderliche Dateien auf zugelassen[/li][/ul]

Und nochmals, es betrifft die Helicon Vollversion…

[QUOTE=pctechnikch;19130]Kontrolliere doch…

[ul]
[li]index.php modifiziert, bzw. ergänzt wie angegeben…
[/li][/ul]
[ul]
[li]stimmt die oxyd config wirklich
[/li][/ul]
[ul]
[li]passt die .htaccess wie angegeben
[/li][/ul]
[ul]
[li]ist die Registerkarte von Helicon vorhanden unter iis
[/li][/ul]
[ul]
[li]sind die Rechte richtig gesetzt über der .htaccess und dem Host
[/li][/ul]
[ul]
[li]Webdiensterweiterungen, erforderliche Dateien auf zugelassen
[/li][/ul]

Und nochmals, es betrifft die Helicon Vollversion…[/QUOTE]

Hi,

  • index.php ist modifiziert, gleich nach dem ersten Kommentarblock eingefügt.
  • die oxid-config ist auch ok, die Startseite und der Adminbereich funktionieren ja, also Datenbank richtig konfiguriert. Oder müssen da noch andere Dinge angepasst werden ?
  • hab inzwischen jede Menge .htaccess Varianten probiert (im Forum von Helicon hat mir jemand noch andere Anweisungen empfohlen, würde aber am liebsten die originalen verwenden bzw. Deine Modifkationen)
    Die Rechte sind die folgenden für root-Verzeichnis der Site und .htaccess: User “Jeder” hat alle Rechte
  • Registerkarte von Helicon ? Was ist das ? In der IIS-Konfiguration (IIS5!) ist ISAPI_Rewrite3 als ISAPI Filter registriert und aktiv (grüner Pfeil), also scheint alles ok zu sein
  • “Webdiensterweiterungen, erforderliche Dateien auf zugelassen” ? Verstehe ich nicht ?

Habe die 45-Tage Testversion (full) im Einsatz. Sie “rewritet” ja, im Logfile sind viele Einträge zu sehen, nur führen sie offensichtlich zu einer Endlosschleife, wie mir die immer wieder kehrende Zeile “escaping /oxseo.php/” suggeriert.

Würde dir gerne mal den Zugriff auf den Server geben, vielleicht ist das das schnellste. Bin ja richtig neidisch, wenn ich deine Test-Site sehe… :wink:

Vielen Dank für die Mühe
Andreas

IUSER auf lesen, ausführen
IWAM auf lesen, ausführen

vorerst beide mal über ganzem Hostverzeichniss.

JEDER greift nicht im IIS!

OXID Standard .htaccess verwenden, unbedingt, sonst weitere Fehlerquellen.

Die Registerkarte von Helicon findest Du wenn man rechte Maustaste über dem Host klickt, dann Eigenschaften…

…ich denke aber, dass das bei Dir alles passt und vermute, es würde an den Rechten liegen, aber eben.

Helicon in ein Webarbeitsverzeichniss installieren, zum Beispiel PHP, oder die Rechte richtig setzen.

Und vielleicht, den noch versuchen …

RewriteEngine On
RewriteBase /

Baseverzeichniss muss auch stimmen, wenn nicht im Host installiert.

Wenn man viel weiss, weiss man dass man nichts weiss, darum weiss ich, dass auch ich an Deinem Server scheiterern kann und es für mich zur Baustelle werden kann, aber schauen wir mal, immer mit der Ruhe.

Hast Du ein Plesk Panel oben?

Und es würde mich enorm freuen für die IIS geplagten, wenn es geklappt hat, dass hier der Erfolg gemeldet würde. Vielen Dank.

[QUOTE=pctechnikch;19443]IUSER auf lesen, ausführen
IWAM auf lesen, ausführen

vorerst beide mal über ganzem Hostverzeichniss.

JEDER greift nicht im IIS!

OXID Standard .htaccess verwenden, unbedingt, sonst weitere Fehlerquellen.

Die Registerkarte von Helicon findest Du wenn man rechte Maustaste über dem Host klickt, dann Eigenschaften…

…ich denke aber, dass das bei Dir alles passt und vermute, es würde an den Rechten liegen, aber eben.

Helicon in ein Webarbeitsverzeichniss installieren, zum Beispiel PHP, oder die Rechte richtig setzen.

Und vielleicht, den noch versuchen …

RewriteEngine On
RewriteBase /

Baseverzeichniss muss auch stimmen, wenn nicht im Host installiert.

Wenn man viel weiss, weiss man dass man nichts weiss, darum weiss ich, dass auch ich an Deinem Server scheiterern kann und es für mich zur Baustelle werden kann, aber schauen wir mal, immer mit der Ruhe.

Hast Du ein Plesk Panel oben?

Und es würde mich enorm freuen für die IIS geplagten, wenn es geklappt hat, dass hier der Erfolg gemeldet würde. Vielen Dank.[/QUOTE]

Hi,
danke für die Hinweise,
Die Rechte hab ich kontrolliert, IUSR und IWAM sind tatsächlich nicht angelegt, wie konnte ich das übersehen ? Hab es einfach nicht beachtet, bisher hab ich jede Menge Webserver einfach so installiert ohne viel konfigurieren zu müssen (den im real-Einsatz natürlich ordentlich geschützt…).
Jetzt haben IUSR und IWAM die folgenden Rechte:
\inetpub: Lesen
\inetpub\wwwroot: Lesen, ausführen, auflisten

hab wieder die standard htaccess eingespielt, aber ohne die Kommentarzeile, und mit RewriteBase /.

Helicon Registerkarte gefunden, manchmal bin ich schon etwas überarbeitet… :wink:
Wenn ich dort die htaccess Datei editiere, motzt er über folgendes:
Unknown expression on line #3: Options +FollowSymLinks
Unknown expression on line #24: order allow,deny
Unknown expression on line #25: deny from all
Unknown expression on line #28: Options -Indexes

Scheint wohl doch nicht ganz kompatibel zu sein…

Danke
Andreas
Sollte ich die Lösung hinbekommen werde ich alle Einzelheiten genau beschreiben und hier posten, versprochen!

In der Registerkarte von IIS kann man die Rules nicht bearbeiten, da das Route Zeichen (#) dort nicht erkennt wird. Wenn man dort editiert, darf man nur Rules verwenden. (Keine Auskommentierungen). Mit dieser Frage, wollte ich mich vergewissern, ob die Installation sitzt.

Dein Shop ist kompatibel mit isapi_rewrite, (deine URL hats mir verraten) die Schlaufen die er zieht, habe ich bei XT-C auf IIS schon erlebt. Werde mal nachhirnen, obwohl ich mich manchmal frage: “Mit was denn?”

Was ich dort gebaut habe, kommt mir nicht gerade in den Sinn. Schick mir mal die config Deines Oxid Shops bzw. die Zeilen mit den Pfaden. DB-Zeugs brauche ich ja nicht, passt ja auch.

Bei XT-C lag es an den Pfaden und Rechten, warum das Isapi Rewrite Zeug schmerzhaft wurde…

…wenn das nicht 100% stimmt, zieht Oxid mit Sicherheit schleifen oder es läuft gar nicht.

Auch wenn der Thread etwas älter ist: Ich bin über Google darauf gestoßen, wird auch anderen so ergehen.

Vorab: Auf meiner Entwicklungsmaschine benutze ich z.Z. noch die Vollversion von Helicons ISAPI_Rewrite. Ich habe OXID CE damit ans Laufen bekommen, allerdings nur durch einen kleinen Eingriff in /index.php und manuelles editieren der config.inc.php.

Was ich aber allen nahelegen möchte, die ebenfalls den IIS verwenden, ist Helicons Ape (APache Emulator). Es ist für bis zu 3 Domains auf dem gleichen Server kostenlos. Man bekommt damit eine ca. 98%-ige Kompatibilität mit Apache für den IIS. Da Ape auch $_SERVER[‘REQUEST_URI’] korrekt setzt, besteht keine Notwendigkeit mehr, /index.php zu patchen. Mir ist nicht bekannt, da ich es nicht ausprobiert habe, ob damit auch die mod_rewrite-Prüfung von oxid klappt, es wäre aber gut möglich.

Eine Sache, die mir nicht verständlich ist, gleichzeitig ist auch etwas, was die oxid-Systemprüfung mit rot moniert, ist, dass die Erkennung der MySQL-Client-Schnittstelle fehlschlägt, obwohl sie vorhanden ist (PHP 5.3.9).

Ehrlich gesagt finde ich die restriktive Systemprüfung bzw. die Systemvoraussetzungen etwas enttäuschend. Es ist unnötig den IIS auszusperren. Alles mögliche an PHP-Webanwendungen läuft klaglos auf IIS 7.x wenn man Helicon Ape verwendet. Wenn sich, wie in meinem Fall, letztendlich herausstellt, dass OXID CE sehr wohl mit lediglich ein paar Handgriffen auf dem IIS ans Laufen zu bekommen ist, dann fragt man sich, was OXID esales dazu bewegt, die Systemvoraussetzungen so eng zu fassen. Kann das wirklich eine professionelle Haltung sein? Es handelt sich ja dem Selbstverständnis nach nicht um eine kleine Software-Klitsche.

[QUOTE=Schlimmer;80157] Wenn sich, wie in meinem Fall, letztendlich herausstellt, dass OXID CE sehr wohl mit lediglich ein paar Handgriffen auf dem IIS ans Laufen zu bekommen ist, dann fragt man sich, was OXID esales dazu bewegt, die Systemvoraussetzungen so eng zu fassen. Kann das wirklich eine professionelle Haltung sein? Es handelt sich ja dem Selbstverständnis nach nicht um eine kleine Software-Klitsche.[/QUOTE]

Das ist doch reine Polemik von dir. Man muss nicht alles machen, was technisch irgendwie möglich sein mag. Wo findet man denn bitte schön die Aussage, das OXID auch Support für den IIS bietet?

[QUOTE=Schlimmer;80157]…dann fragt man sich, was OXID eSales dazu bewegt, die Systemvoraussetzungen so eng zu fassen.[/QUOTE]

Wahrscheinlich bekommt Oxid Provision von Apache…

Mal im Ernst, Apache ist einfach am weitesten verbreitet. Und selbst hier ist es schon schwierig, die unterschiedlichsten Konfigurationen zu berücksichtigen. Das Zusammenspiel von Apache, Linuxdistribution und Version, MySQL, PHP und was weiß ich noch alles mehr eröffnet bereits eine schier unhandhabbare Variantenvielfalt.

Aus dem gleichen Grund gibts javon Oxid auch extra CSS für den Internet Explorer 7, 8 und 9 - aber nicht für Safari, Maxthon oder Sleipnir…

Wer “exotische” Lösungen einsetzt, bzw. überhaupt auf die Idee kommt diese einzusetzen, der hat im Normalfall auch genügend Wissen, wie man den Rest der Welt kompatibel bekommt. Zumindest weiß er, wo man suchen kann.
Und mal im Ernst, IIS ist mit Sicherheit zu vernachlässigen, zumindest was Webserver angeht.

[QUOTE=Hebsacker;80166]
Und mal im Ernst, IIS ist mit Sicherheit zu vernachlässigen, zumindest was Webserver angeht.[/QUOTE]

Naja, speziell im Umfeld vom großen Firmen/Unternehmen gibt es schon etliche Einsatzgründe für den IIE. .NET und Konsorten sind schon mächtige Tools.

Das Problem ist oft nur das Personal. Die wollen und können öft nichts anderes als Windows. Getreu dem Motto bloß keine Veränderungen.
Hat mich bei meinem alten Arbeitgeber etliche Jahre gekostet, denen andere Tools schmackhaft zu machen.

In einem anderen Thread konnte ich lesen, dass es gegenwärtig (unabhängig von IIS) ein Problem mit checkMysqlConnect() in core/oxsysrequirements.php gibt. Wenn man sich sicher ist, dass mit der MySQL-Anbindung alles in Ordnung ist, kann man als Umgehungsmaßnahme dort zu Beginn der function einfach ein return 2; einsetzen, um die MySQL-Client-Prüfung auszutricksen. Hat wie gesagt nichts mit IIS zu tun.

Nun habe ich Helicon Ape installiert. Und siehe da: Ohne auch nur eine einzige Änderung (also auch .htaccess unverändert gelassen) lässt sich nun das ganz normale Setup-Prozedere ausführen, so wie es auch unter Apache der Fall wäre. Sowohl Shop als auch die Shop Administration funktionieren so wie es sein soll. Einzige, wenn man so will, Abweichung: Die Verzeichnisrechte werden unter Windows natürlich nicht mit chmod gesetzt.

Die Systemprüfung, sowie die Angabe der Systemvoraussetzungen, könnte man also durchaus etwas weiter fassen.

[QUOTE=ChristophH;80162]Das ist doch reine Polemik von dir. Man muss nicht alles machen, was technisch irgendwie möglich sein mag. Wo findet man denn bitte schön die Aussage, das OXID auch Support für den IIS bietet?[/QUOTE]

Langsam. Es ging mir wirklich nicht um’s Polemisieren oder Bashing. Es ist nur so, dass ich einen Kunden habe, der einerseits auf PHP steht, andererseits dabei auf ein paar COM-Komponenten angewiesen ist, und zudem den IIS verwendet. Bei dem laufen PHP-Websites seit über 10 Jahren auf IIS, und zwar performant und ohne Probleme. Früher sogar mit der oft als kritisch dargestellten ISAPI-Variante. Und zwar Websites, die durchaus einen ordentlichen Traffic haben. Weil es ein für mich wichtiger Kunde ist, arbeite ich bei der PHP-Entwicklung auch seit über 10 Jahren mit dem IIS. Selbst wenn das Produktivsystem eine LINUX-Maschine ist. Einfach weil die parallele Installation von IIS und Apache auf der gleichen Entwicklungsmaschine bisher niemals nötig war. Und das, obwohl ich Webentwicklungen zu nahezu 100% mit PHP mache. Ich war also lediglich überrascht, dass ausgerechnet OXID CE hierbei nicht mitspielen wollte.

Das sich der OXID Shop unter IIS mit Helicon Ape nun genauso verhält, wie er es sollte, deutet für mich schon darauf hin, dass die Systemanforderungen zu eng gefasst sind.
Falls ich nun, wieder erwarten, auf Probleme mit dieser Konfiguration stoßen sollte, werde ich mich natürlich korrigieren und hier berichten.

Danke für die (positive) Rückmeldung! Und klar, wir hören gerne weitere Infos!