“Hosting Plus“ ist nicht gleich “Hosting Plus“

Alle paar Jahre bekommen die Strato Webhostingpakete (und auch die Serverprodukte) eine Art Facelift mit neuen Features oder auch anderen Preisen. Dabei ändert sich der Name des Produktes nicht zwangsläufig. Eher gibt es ab einem solchen Zeitpunkt eine neue Version des Paketes, in meinem Fall eine neue Version des Paketes „Hosting Plus“.

Das Paket kostet immer noch 10€, die neue Version hat aber nun 10-Inklusiv-SSL-Zertifikate, statt vorher nur einem. Und genau das war für mich interessant, denn die übrigen SSL-Zertifikate musste ich bisher über eine teure SSL-Flat hinzukaufen. Somit hatte ich großes Interesse daran, mein altes Paket auf das aktuelle umzustellen.

Flexibel wie eine Salzstange

„Ich kann Ihnen Ihr altes Hosting Plus Paket nicht auf das aktuelle Hosting Plus Paket upgraden. Das geht leider nicht. Sie können ein neues „Hosting Plus“ Paket abschließen und Ihre Daten und Domains dann dahin umziehen. Danach könnten Sie Ihr altes Paket kündigen.“

Ja, coole Idee. 20 Postfächer mit Mails verlieren und Downtimes auf 8 Domains in Kauf nehmen. tolle Idee – nein danke.

„Sie können Ihr Hosting Plus Paket in ein Hosting Pro Paket wandeln, dann kriegen Sie mehr Inklusiv-SSL-Zertifikate. Ein Upgrade ist immer möglich“.

Ja klar, weil das auch nur das Doppelte kostet. Ausgebuffte Geschäftsleute seid ihr. Nein danke.

Fast hätte ich den Quatsch geglaubt.

Fuck the system

Jetzt kommt der Hack / Workaround:

Und dann habe ich mein altes „Hosting Plus“ Paket auf ein neues (2020er) „Hosting Pro“ Paket geupgradet. Das ging online.

Nachdem das „Hosting Pro“ aktiviert war, rief ich die Hotline an und hatte nach 21 Minuten dann eine Beraterin dran. Diese bat ich das „Hosting Pro“ für eine einmalige Gebühr von 20€ auf das aktuelle „Hosting Plus“ zu downgraden. Denn das geht laut Strato Knowledgebase jederzeit: Recht auf Downgrade gibt es immer – gegen Gebühr.

Die Dame am Telefon war etwas verdutzt: „Sie haben doch heute Morgen erst geupgradet?“ stellte sie verwirrt fest. Ich erklärte ihr den Sachverhalt und sie fragte mich „Und dieses Vorgehen wurde Ihnen von den Kollegen empfohlen?“. Ich zögerte einen Moment, nein, die Strategie hatte ich mir selbst überlegt. Vorsichtshalber sagte ich trotzdem ja. Besser wenn sie sich nun verpflichtet fühlen würde dieser Empfehlung nun auch nachzukommen. Schließlich bestätigte sie mir, dass mein Paket nun downgegradet werden würde.

Siehe da, schon hatte ich nach 48 Stunden ein aktuelles Hosting Plus-Paket in dem ich keine zusätzlichen SSL-Zertifikate mehr extra kaufen musste. Meine SSL-Flat konnte ich nun kündigen, und habe nun ein aktuelles Hosting Plus Paket zur Verfügung.

Ich freue mich immer wenn man einen beschissenen Prozess besiegt. Wenn dieser Beitrag nun noch anderen hilft – umso besser.

Der Beitrag Strato Hostingpaket aktualisieren – über Umwege ohne Upgrade und Neubuchung erschien zuerst auf Pixelfriedhof.

The german Axel Springer publishing company demonstrates a way to block ad-blocking users from their content since october ’15. Free-to-view webpages of the BILD-newspaper are blocked until the visitor deactivates his ad-blocker. This step is also interesting for smaller websites or blogs, only financing themselves through ad-placements. Here is how to block ad-blocking users from your content.

English version see below.

<Moralapostel>

Schau mich an: Ich betreibe diese Webseite für meine Besucher kostenlos. Sie dient mir zwar auch als Gedankenstütze und zur Dokumentation selbst gelöster IT-Probleme, doch einen größeren Nutzen sollte sie für Nutzer haben, die sich für die Lösung eines hier behandelten Problems interessieren. Als Gegenleistung dafür blende ich Werbung von Google Adsense ein. Zwei Banner, einmal rechts vom Content, einmal darunter. Wirklich stören tuen diese den Nutzer in meinen Augen nicht.

Ich bin auf die Werbeeinnahmen nicht angewiesen. Das wäre auch schön blöd bei den verhältnismäßig geringen Nutzerzahlen dieser Seite. Doch ich freue mich über die jährliche Auszahlung der Einnahmen, die auch ein Stück weit ein Honorar für mich und die hier bereitgestellten Inhalte darstellt. So hart es klingt, ich bin von dieser Seite nicht abhängig und auch nicht von den Besuchern. Schon garnicht abhängig bin ich von Besuchern die meine Seite zwar besuchen, aber dann vorsätzlich meine Werbung ausblenden. Aus diesem Grund habe ich mich für die Implementierung eines Ad-Block-Schutzes entschieden, auch als eine Art „Selbstversuch ohne Konsequenzen“.

Um den Nutzer eines Werbeblockers erfolgreich auszusperren benötigt man entsprechende Scripte um diese Nutzer (vielmehr deren Browser) erfolgreich zu identifizieren. Diese Scripte schauen auf Basis bestimmter Muster und Blacklists nach, ob der Besucher über ein aktives und als Werbeblocker agierendes Add-On verfügt.

Es gibt viele Ansätze gegen Adblocker im Netz, doch längst nicht alle funktionieren zuverlässig. Das Problem ist häufig, dass ein kleines Projekt ein wirksames Script gegen Ad-Blocker veröffentlicht, dieses dann aber sehr schnell von den großen und finanziell starken Ad-Block-Betreibern umgangen wird. 

Warum sind die Hersteller finanziell so stark aufgestellt? Weil Sie gegen Zahlung großer Summen bestimmte Werbung eben doch zulassen. Und diese Eigenschaft macht die Hersteller dieser Ad-Blocker eben nicht zu den Samaritern der Internet-Surfer, sondern zu einer die Netzneutralität gefährdenden, schmarotzenden Mafia. Wegelagerer des Internets, Erpresser. Diese Organisationen verdienen Geld mit einer Leistung, die man ohne sie nicht bräuchte. Und jeder Nutzer mit aktivem Ad-Blocker hilft Ihnen ein Stück weiter zu Ihrem Zeil, dass in Zukunft die Ad-Blocker bestimmen, was die User zu sehen bekommen. 

Schluss mit meinem idealistischen Geschwafel. Doch ich glaube so mancher User weiß garnicht, was er da eigentlich unterstützt.

</Moralapostel>

Ich habe also in den letzten Tagen verschiedene Maßnahmen geprüft und musste feststellen dass viele der Projekte, gerade Add-Ons für CMS-Systeme, garnicht, oder nur sperrlich funktionieren.

Fündig wurde ich schließlich bei dem Projekt Antiblock.org. Dieses Projekt scheint nicht nur aktiv entwickelt zu werden, es funktioniert nach meinen Tests auch am zuverlässigsten und bietet zudem einen leicht zu bedienenden Konfigurator zur Erstellung der benötigten Scripte. So kann festgelegt werden, ob der Nutzer nur um die Deaktivierung des Ad-Blockers gebeten wird, dann aber fortfahren kann, oder ob er strikt am Besuch der Seite gehindert werden soll. In den Scripten enthalten ist zudem die Möglichkeit Nutzer, deren Browser-Add-Ons nicht durch Javascript ausgelesen werden können, gleich mit auszusperren. Also Nutzer von z.B. „No-Script“ oder ähnlichen Tools.

Der erstellte Code wird im Body-Bereich der Webseite eingebettet und ist somit CMS- oder Plattform-unabhängig.

Mit aktiviertem Adblocker erhält der Nutzer eine als Grafik angezeigte Meldung zu den Details der Einblendung/Sperrung. Der hier angezeigte Text kann frei konfiguriert werden. Eine Auswirkung auf die SEO-Performance der Website sollte das Tool nicht mit sich bringen, da die Crawler der Suchmaschinen keinen Javascript nutzen.

Auf alle Fälle einen Test wert!

 English version

<virtuecrat-mode>

Look at me: I maintain this website for my visitors without asking for fees. Yes, i use it as a kind of storage for my own solved, or unsolved it-problems, but it should be of greater use for those, searching for one of my published solutions. As some kind of reward for that, I implement ads from the google adsense-network. Two banners, one on the right side, one at the bottom of my content. I don’t think that these kinds of ads disturb my visitors.

To be honest, my life doesn’t depend from what I earn with online-ads. That would be incredibly stupid, because due to the low visitor-counts I gain compared to other major websites, i couldn’t afford anything. Besides I see the yearly payment as some kind of reward for my efforts and my work. As hard as it sounds, you see I am totally independent from my visitors and especially from people who visit my site, knowingly circumventing my ads. Based on this fact, I decided to implement a defense against ad-blockers. I see it as an experiment without consequences.

To lock a user of an ad-blocker out of your site, one needs special scripts to identify those users and their browsers. These scripts look for patterns and blacklisted applications to identify if there are active add-ons like ad-blockers.

The internet is full of projects aiming to protect websites from ad-blockers, but a majority is either not working correct or is completely useless. The problem is, that a small group of activists releases a new defense mechanism, but the financially stable publishers of the ad-blockers circumvent the effort in nearly real-time.

Why are those publishers financially so strong? Because they are bribable. They let ads of paying publishers through their systems, so called „acceptable ads“. This  virtue is what doesn’t make the publishers a good samariter for everyone surfing the web, it makes them a thread to net-neutrality. It makes them a mafia, it makes them the extorting buccaneers of the web. These organisations earn money with a service that would, without them, be totally redundant. Every user with an activated ad-blocker backs them and helps them to control what the user will see in the future. 

So far with my own opinion on ad-blockers in general. But I think that only a minority of users know, what they’re actually supporting with ad-blockers.

</virtuecrat-mode>

During the last few days I evaluated different approaches of ad-blocking-defenses, finding out many of them, especially for CMS‘ are simply not working.

The best solution I could find is  Antiblock.org. This project doesn’t only seem to be actively developed, it is, as my tests showed, more stable, reliable and easier to configure than all the other approaches. It comes with a web-based generator for the script. The user can decide if the visitor should only be asked to turn off his or her ad-blocker or if he or she should be forced to do so by completely locking him or her out of the site. The script gives the choice to also lock out people using browser-add-ons that determine the use of java-script, which is needed to identify active ad-blockers. E.g. extensions like „No-Script“.

The generated Code is placed inside the websites body. This way, the solution is independent from the plattform.

With an activated ad-blocker the visitor receives a warning, generated as a graphic, which gives details to the on-screen-mesage or lock-out. This text can be altered in the code of the generated script. There shouldn’t be an impact on seo-performance, as no crawler uses javascript.

You should give it a try.

Der Beitrag Ad-Blocker-Nutzer effektiv blockieren / Block Ad-Blocker-user erschien zuerst auf Pixelfriedhof.

Der Beitrag IIS Grundlagen – Webseiten hosten und Bindungen verwalten erschien zuerst auf Pixelfriedhof.

Bei dem Versuch, eine ICS-Internetkalenderdatei mit dem IIS zu hosten und den Kalender mit mobilen Geräten abonnieren zu können, gibt es einige kleine Hürden, die einen an den Rande eines Nervenzusammenbruchs treiben können.

Im Rahmen einer von mir durchgeführten konzeptionellen Softwareberatung wollte ich unter einer Site im Internet Information Server eine ICS-Datei hosten. Die ICS Datei sollte von einem Drittprogramm generiert werden und Kalenderdaten für einen Mitarbeiter beinhalten. Im Anfangs- und Qualifikationsstadium legte ich keinen Wert auf eine vorgeschaltete Authentifizierung und wollte somit jedem der die URL des Kalenders kennt Zugriff auf das Kalenderabonnement geben.

Wenn man nach diesem Sachverhalt im Internet sucht, stößt man unweigerlich auf die Abkürzungen CalDAV und WebDAV. Obwohl die sehr nah mit unserer Thematik zusammenhängen, brauchen wir diese erstmal überhaupt nicht. Weil: Wir wollen nur hosten und mobil lesend auf eine ICS-Datei zugreifen. Würden wir in dieser ICS-Datei später seitens des mobilen Nutzers auch Änderungen vornehmen wollen, dann und nur dann, bräuchten wir tatsächlich CalDAV und WebDAV. Da unser Drittsystem aber die Daten generiert (bzw. mein konzeptionierter Adapter diese Daten erstellt) brauchen wir uns um Schreibrechte auf der Clientseite garkeine Gedanken machen.

Also überspringt einfach sämtliche schlauen Ratschläge zum Thema CalDAV und WebDAV.

Zur Bereitstellung der Datei habe ich eine Site im IIS angelegt. In ein Verzeichnis darin dann die bereitgestellte ICS-Datei abgelegt.

Durch die Bindungen habe ich die Site einer Subdomain zugewiesen und dachte nun: „Prima, jetzt den Link zur gehosteten ICS-Datei per Mail verschicken, dann kann der abonniert werden.“.

Fehlanzeige. Das iPhone und andere Endgeräte quittieren beim Versuch der Verbindung mit der Meldung „Der Kalender XYZ kann nicht abonniert werden.“

Schuld daran ist nicht etwa ein Berechtigungsproblem wie zuerst vermutet, sondern eine im Standard falsch hinterlegte Einstellung in den MIME-Typen des IIS Servers. Also klicken wir auf die eben angelegte Site im IIS und wechseln auf die Schaltfläche für die MIME-Typen.

In der nun erscheinenden Liste suchen wir den Eintrag für die Datei Erweiterung ICS. Die hinterlegte Eigenschaft „application/octet-stream“ ist schlichtweg falsch. Das Internet schlägt bei der Websuche noch mehr falsche, alternative Einträge vor. Der einzig richtige Eintrag für die ICS-Formate ist hier „text/calendar“.

Et Voilà: Wenn wir den Link nun erneut öffnen, fragen uns das iPhone und andere Geräte und Apps, ob wir den Kalender importieren oder abonnieren wollen.

Zwei Tipps noch: Um die Kompatibilität mit Kalender-Apps und weiteren Diensten wie Google Calendars, etc. zu erhöhen: das HTTP:// der Kalender-URL durch ein WEBCAL:// ersetzen.

Webcal hat wirklich garnichts mit CalDAV zu tun. Es handelt sich lediglich um ein Pseudo-Protokoll zur Auswahl des richtigen Handlers.

Tipp 2: Wenn Änderungen in der ICS-Datei vorgenommen werden, erwartet bitte keine aktive Push-Benachrichtigung auf Eurem Endgerät. Läuft nicht. Da reden wir von ganz was anderem. Das Refresh-Intervall des Endgeräts bestimmt hier wann die Aktualisierungen vom Server geholt werden. Und wenn Ihr diese ICS-Datei nun bei Google Kalender einbinden wollt, damit Sie auf Eurem Android-Smartphone bereitsteht, dann willkommen in der häufig kranken Welt von Google:

Ihr könnt einen Kalender per URL hinzufügen. Kein Problem. Aber Google cached die von dort abgeholten Daten und je nach Auslastung kann es vorkommen, dass Google den Kalender erst nach 43 Stunden aktualisiert. 

Das Problem ist seit 2009 bei Google bekannt. 2014 äußert sich ein Google Engineer im entsprechenden Productforum ungefähr so: „Wir wissen, dass es da Probleme gibt, aber geht nicht davon aus, dass sich da in nächster Zeit was ändern wird.“

<ironie>Ist ja auch nicht so wichtig, dass eine Kalenderapp, nach der viele von uns jeden Tag flexibel Ihren Alltag organisieren, aktuell ist.</ironie>

Kriegt endlich Eure Schnittstellen auf die Reihe, Google und kommt im Jahr 2014 an. Es geht hier nicht um selbstfahrende Autos oder Glasfaseranbindungen in jedes Haus. Es geht nur um einen Kalender der aktuelle Daten anzeigt.

Der Beitrag ICS-Kalender mit IIS hosten – Meldung „Kalender abonnieren nicht möglich“ umgehen erschien zuerst auf Pixelfriedhof.

Das Tool „Guess“ ermöglicht es uns mit wenig Aufwand und ohne direkte Nachverfolgung unseres Clients grundlegende Informationen zu einer vorleigenden Website anzuzeigen.

Der momentan noch experimentelle Dienst beeindruckt mit einer hohen Erkennungsrate unterschiedlichster Plattformen wie Webservern, Frameworks und darauf basierenden, evtl. genutzten Content-Management-Systeme.

Nach einem Klick auf „Fetch“ liefert das gleichnamige Tool weitere Informationen zur untersuchten Seite:

Eine Analyse der verwendeten Scripte liefert unter Umständen auch Informationen über den vermeintlichen Versionsstand verwendeter Plugins oder Extensions. Dies liefert Administratoren und Angreifern unter Umständen nützliche Informationen:

Hier geht es direkt zum Tool: Link „Guess – the CMS web framework detector“

In diesem Zusammenhang sind vielleicht auch meine Beiträge zum Google-Tool PageSpeed Insights und dem V3C-Validator interessant.

War dieser Artikel hilfreich? Dann freue ich mich über ein kleines Danke oder Kommentare:

Der Beitrag CMS / Framework einer Website analysieren erschien zuerst auf Pixelfriedhof.

Persönliche kenne ich viele Firmen und Institutionen, die wenn es um Suchmaschinenoptimierung und Onlinemarketing geht, keine Kosten und Mühen scheuen – allerdings nicht immer ganz sinnvoll. Aber wozu gibt es Agenturen und Profis, wenn das ganze Thema so einfach wäre.

Ein in meinen Augen nicht unbedeutender Teil der Voraussetzungen für eine ordentliche Gesamtperformance der Webseite im onpage-SEO Bereich ist die technisch einwandfreie Umsetzung.
Webcrawler und Suchmaschinen betrachten auch diese Eigenschaften von Webseiten und messen der Veröffentlichung dann eine hohe, oder niedrige Bewertung bei.

Heute möchte ich kurz das Google-Tool „PageSpeed Insights“ vorstellen, welches uns detailierte Informationen zu technischen Schwachstellen in unserer Webseite liefert. Über einen Reiter oberhalb der Analysedaten können wir zwischen der Auswertung für mobile Geräte und der Desktopversion umschalten. Je nach Auswahl werden der analyse unterschiedliche Kriterienkataloge zu Grunde gelegt, da die durchschnittlichen Anbindungsdatenraten von Mobil- und Desktopgeräten bekanntlich stark voneinander abweichen können.

Nach simpler Eingabe der zu untersuchenden Webseite und einem Klick auf „Analyze“, gibt uns das dem Google Developerprogramm angehörende Tool, detailierte Informationen über die die Leistung beeinträchtigenden Elemente.

Sicherlich lassen sich ähnlich wie beim W3C-Validator nicht immer alle Punkte beheben, aber schon das Beheben wesentlicher Punkte trägt zur enormen Verbesserung der Gesamtperformance bei. Diese Optimierungen wirken sich idealerweise nicht nur auf die Statistik, sondern gleichermaßen auf externe Bewertungen und den Nutzerkomfort aus. Mit etwas Geduld werden wir die Leistungsverbesserung je nach Optimierungspotential auch an Conversionrates und Absprungraten merken.

Hier geht es direkt zum Tool: Link „Google PageSpeed Insights“

In diesem Zusammenhang sind vielleicht auch meine Beiträge zum V3C-Validator und zum Guess, einem CMS- und Frameworkdetektor, hilfreich.

Mein langjähriger Bekannter Julian Pustkuchen hat zu dieser Thematik weitergehend Beiträge für zwei weitere Ansatzpunkte technischer Optimierung verfasst. Einmal im Bezug auf die Performancesteigerung des Content-Management-Systems Drupal und zweitens für das Tuning von mySQL. Vielleicht schaut Ihr hier auch einmal vorbei. Letzteres Thema sollte einen Großteil der Webanbieter interessieren.

War dieser Artikel hilfreich? Dann freue ich mich über ein kleines Danke oder Kommentare:

Der Beitrag Optimierungspotentiale in der Serverperformance finden und nutzen erschien zuerst auf Pixelfriedhof.

Ich persönlich denke, dass es nur von Vorteil seien kann, seine Seite bei Bing zu platzieren. Gerade wenn der Aufwand dafür sehr gering ist. Bisher kannte ich nur den Weg über Microsoft’s Tool „Webmaster Central“, ein Pendant zu Googles „Webmaster Tools“. Zu viel Aufwand. Hier lest Ihr wie Ihr eine XML-Sitemap direkt an Bing senden könnt, ohne den Weg über „Webmaster Central“ gehen zu müssen.

Das Vorgehen zur Einreichung einer XML-Sitemap bei Bing ist denkbar simpel. Kopiert einfach die folgende Zeile Code und setzt hinter das Gleichheitszeichen Euren Link mit „www.“ anstelle des Beispiels:

http://www.bing.com/webmaster/ping.aspx?sitemap=www.domain.de/sitemap.xml

Diesen Link müsst Ihr dann einfach über die Adresszeile Eures Browsers aufrufen. Wenn alles geklappt hat, quittiert der Bing-Bot (schöne Alliteration) mit einem unverschnörkelten „Vielen Dank für das Senden Ihrer Sitemap.„

Wie man es von Microsoft’s Detailverliebtheit erwartet, tut er das allerdings auch, wenn man kompletten Bullshit übermittelt hat. 

Achtung: Ich befürchte, dass es nicht ratsam ist, mehrere Adressen von einer IP und einer Session schnell hintereinander an den Index zu senden. Das ist aber nur eine Vermutung. Wäre ich verantwortlich für die Annahme der Sitemaps in Microsoft’s Webdienst, würde ich danach filtern. Andererseits, was will man erwarten, wenn das System nicht mal quittiert, dass der Nutzer gerade Müll übermittelt hat.

Der Beitrag XML-Sitemap ohne Microsoft Webmaster Central bei Bing eintragen erschien zuerst auf Pixelfriedhof.

Zunächst müssen Sie eine Sicherung Ihrer bisherigen Webpräsenz erstellen. Diese beinhaltet sowohl die Datenbank als auch das Dateisystem. Kopieren Sie das Rootverzeichnis Ihres FTP-Servers auf Ihre Festplatte. Je nach größe der zu exportierenden Seite und der Internetanbindung kann dieser Vorgang durchaus länger dauern. Eventuell ist es sinnvoller den FTP-Client direkt auf dem Zielserver auszuführenum sich diverse Transporte unter Clients und Servern zu ersparen und gegebenenfalls auch die Internetanbindung auszunutzen. Während der FTP-Client die Daten transferiert können Sie beginnen (wenn vorhanden) sich in die PHPMyAdmin-Seite ihres bisherigen Webpakets einzuloggen. Wählen Sie die passende Joomla-Datenbank aus und klicken Sie auf „Exportieren“. Im folgenden Fenster setzen Sie folgende Atribute: Exportieren -> SQL SQL-Optionen -> Struktur SQL-Optionen -> Struktur -> Auto_INCREMENT-Wert hinzufügen SQL-Optionen -> Struktur -> Tabellen- und Feldnamen in einfachen Anführungszeichen SQL-Optionen -> Daten SQL-Optionen -> Daten ->Hexadezimalschreibweise für Binärfelder verwenden SQL-Optionen -> Senden SQL-Optionen -> Zip-komprimiert, Konvention merken, Dateinamenskonvention „__DB__“ Anschließend klicken Sie auf OK und speichern den erstellten Zip-Datenbankdump auf dem neuen Server. Es geht nun weiter mit der Einpflegung der Daten auf dem neuen Server. Überspielen Sie das gesammten FTP-Backup in das Rootlevel des neuen Servers. Dieses entsteht wenn Sie eine neue Website im IIS anlegen. Währenddessen loggen Sie sich in die PHPMyAdmin-Konsole des neuen Servers ein. Legen Sie hier eine neue Datenbank an. Der Name der neuen Datenbank muss nicht zwangsläufig dem der vorherigen, ursprünglichen entsprechen. Nach dem Erstellen der Datenbank müssen Sie in der Funktionsleiste oben auf „Importieren“ klicken, anschließend auf die Schaltfläche „Durchsuchen“ und die vorher gespeicherte ZIP-Datei hochladen. Nun stehen die Daten auf dem neuen Server vollkommen zur Verfügung. Auf der nächsten Seite erhalten Sie informationen dazu, wie Sie die Installation so anpassen, dass Joomla auch auf die Datenbank zugreifen kann und wie die Suchmaschinenfreundlichen URLs auch auf einem Nicht-Apacheserver verwendet werden können… Um die Installation jetzt fertigzustellen gibt es noch einige Eigenarten des IIS oder des Apache-Servers zu beachten. Öffnen Sie auf dem neuen Server die Datei „configuration.php“ im Rootverzeichnis der neuen Joomlainstallation. Hier muss die Adresse oder der DNS-Name des bisherigen Datenbankservers in „localhost“ geändert werden. Ebenfalls müssen die Datenbanknutzer und deren Passwort passen. Nun sollte sich zumindest die erste Seite der Joomla-Website auf dem neuen Server öffnen lassen. Wenn wir allerdings auf einen Link klicken erscheint meistens ein Fehler. Dieser entsteht durch falsche URLs die durch das CMS aufgerufen werden, weil wir sehr wahrscheinlich früher die Option „Suchmaschinenfreundliche URLs verwenden“ aktiviert hatten. Diese Funktion nutzt die Funktion „mod_rewrite“ des Apache-Server und eben diese Funktion gibt es im IIS schlichtweg nicht. Damit auch der IIS die „mod_rewrite“-Anfragen bedienen kann erfordert es eine abgeänderte „Web.configuration“ des IIS im Rootverzeichnis der Website. Hier gibt es die Datei im ZIP-Format zum Download. Es handelt sich um die Standard „Web.configuration“ des IIS, erweitert um die „mod_rewrite“-Funktion. Mit dieser Datei einfach die bereits im Ordner befindliche Datei überschreiben und der Ausflug dürfte gelungen sein. Sollte es jetzt noch Probleme geben, loggen Sie sich in das Admin-Backend ein und überprüfen Sie die Einstellungen zu Suchmaschinefreundlichen Links und dem angehängten Suffix. Sollte die Seite nicht wie gewohnt funktionieren schalten Sie entweder beide ab oder an und überprüfen Sie die „configuration.php“ oder die Schreibweise der htaccess-Datei Lassen Sie sich beim Aktivieren der Suchmaschinenfreundlichen-URLs nicht durch die Warnung „Nur für Apache Webserver“ abschrecken. Dank der „Web.configuration“ können Sie die Funktion ruhigen Gewissens aktivieren.

Der Beitrag Joomla Umzug: Von Apache zu IIS7 migrieren erschien zuerst auf Pixelfriedhof.