KI / AI als Werkzeug und nicht als Konkurrenz?

Veröffentlicht am Mittwoch, 12 August, 2026 von Frank König

Muss ich heute noch alles selbst programmieren?

Ich kenne einige sehr gute Entwickler, die künstliche Intelligenz beim Programmieren grundsätzlich ablehnen, das kann ich aus einer Sicht verstehen, man hat das Gefühl, alles unter Kontrolle zu haben, eigenen Code, eigenes Werk.
Wer über viele Jahre gelernt hat, Software zu entwickeln, HTML, CSS, PHP und JavaScript wirklich beherrscht und seine Arbeit mit viel Erfahrung erledigt, möchte vielleicht nicht plötzlich eine KI daneben setzen, die Code produziert.

Ich sehe das allerdings etwas anders.

Für mich ist KI kein Konkurrent, sondern ein Werkzeug.

Natürlich hätte ich mein wirklich altes WordPress-Theme auch ganz klassisch auf Responsive Design umbauen können. Ich könnte mich hinsetzen, den vorhandenen Code vollständig analysieren, jede CSS-Regel nachvollziehen, Media Queries schreiben, testen, Fehler suchen und anschließend alles wieder korrigieren.
Wenn ich genügend Zeit investiere, bekomme ich nebenbei wieder Routine und das ist durchaus ein Vorteil.

Aber die Frage ist für mich: Muss ich diese Zeit investieren, wo es doch KI gibt?

Wenn mein Ziel lautet, meine Webseite möglichst schnell auf einen aktuellen technischen Stand zu bringen oder zumindest so als ob, dann lautet die Antwort nein. Ich habe Zugriff auf KI und kann sie nutzen.

Ich kann der KI erklären, was ich erreichen möchte, mir Vorschläge für die Umsetzung geben lassen, den erzeugten Code prüfen, ihn testen und anschließend gezielt korrigieren. Dadurch spare ich Zeit und Arbeit.
Und diese Zeit kann ich für andere Dinge verwenden, wie Garten gießen oder meiner Frau zuhören.

Das bedeutet für mich nicht, dass ich weniger über Webentwicklung wissen muss, im Gegenteil. Ich muss wissen was ich will, den Code der KI verstehen und einbauen können und testen, ob er tut was ich wollte. Aber ich muss nicht mehr jede Codezeile selbst schreiben, um die Kontrolle über das Ergebnis zu behalten.

KI ersetzt den Entwickler nicht aber sie kann den Entwickler schneller machen, seine Ideen (oder meine) verwirklichen. Ein guter Entwickler mit KI ist deshalb für mich kein schlechter Entwickler, im Gegenteil, er weiß den Vorteil zu nutzen. Er hat ein zusätzliches Werkzeug zur Verfügung.

Wenn ich durch KI fünf Stunden Arbeit spare und das Ergebnis anschließend genauso gut oder sogar besser ist, kann ich diese fünf Stunden für andere Aufgaben verwenden. Für mich ist das keine Konkurrenz zum Programmierer, wie manche meiner Kollegen es sehen, sondern eine Hilfe.

Früher hatte ich ein Entwicklerteam, heute habe ich KI.

Ich war mal sowas wie ein Chefentwickler und musste ein Team leiten und betreuen und was habe ich da gemacht? Ich habe nicht jeden Code selbst geschrieben, ich habe schreiben lassen und erklärt, was ich haben will und habe deren Code geprüft, bevor er ins Live-System hochgeladen wurde. Was ist das anders als nun mit KI ?

Natürlich gibt es einen wichtigen Unterschied: Ein menschlicher Entwickler denkt, versteht Zusammenhänge und kann eigene Entscheidungen treffen, die auch nicht immer sinnvoll und zielführend sein müssen. Eine KI arbeitet anders und kann durchaus überzeugend aussehenden Unsinn produzieren, ok.
Deshalb muss man die Ergebnisse einer KI genauso kritisch prüfen wie den Code eines Mitarbeiters.

Aber genau das ist für mich nichts völlig Neues.
Als Teamleiter war meine Aufgabe auch nicht, jede Codezeile selbst zu schreiben.
Ich brauche niemanden mehr, der mir zum Beispiel eine Latte an Regulären Ausdrücken entwickelt und testet (man kann viel Zeit damit verbringen).
Ich muss keine Flöhe mehr hüten, weil mir die KI gehorcht (tut sie das?) und gefühlt tut, was ich will und (noch) kein Eigenleben entwickelt. Den Überblick über den Code musste ich damals wie heute behalten, heute leichter als damals.

Die andere Seite ist, ich brauche diese Leute wirklich nicht mehr unbedingt für banale Aufgaben, das macht die KI.
Insofern verdrängt die KI durchaus Programmierer, macht sie obsolet.
Aber die KI verdrängt (bisher zumindest) keinen Entwickler, der weiß wohin er will und was gemacht werden soll und den Roten Faden im Auge behält, also das Projekt.
Der KI fehlt die Eigeninitiative, sie weiß nicht, was sie entwickeln soll, wenn man es ihr nicht sagt.
Und das kann ihr eigentlich nur ein guter Entwickler sagen, zumindest einer mit Erfahrung.

Sehe ich das zu blauäugig oder liege ich da richtig?
Bisher bin ich von Tag zu Tag mehr begeistert von den Möglichkeiten durch die KI.

Veröffentlicht in Allgemein, Webdesign | Getaggt | Kommentare deaktiviert für KI / AI als Werkzeug und nicht als Konkurrenz?

Google SEO Bildersuche am Beispiel des Kommutators

Veröffentlicht am Dienstag, 21 Mai, 2019 von Frank König

Am Sonntag 10. Juni 2007 hatte ich das Foto eines Kommutators eingestellt, um zum einen das Wesen von Produktfotos etwas zu erklären als auch das Bild für Suchmaschinenoptimierung (seo) zu verwenden. Damals war alles noch nicht so klar wie heute, vieles musste erst durch eigene Tests herausgefunden werden, was die Suchmaschinen, insbesondere Google, so treiben (Man erinnere sich noch an den Wettstreit um „Grüne Tomaten„, bei dem einige Suchmaschinenoptimierer damals mitgemacht hatten). Zu der Zeit im Jahre 2007 war den meisten Web-Menschen noch nicht so klar wie heute (?), dass sie ihre Bilder im Web mit sinnvollen Namen benennen sollen und nicht einfach von der Kamera hochladen.
Sie verschenken wertvolle Suchtreffer.
Nun denn, ich hatte also vor noch längerer Zeit ein Foto eines Kommutators gemacht, der zum einen tiefschwarzen Kunststoff enthält als auch hochglänzendes Kupfer, das jedes Licht reflektieren würde.
Für eine Consumer-Digitalkamera zu der Zeit damals eine hohe Herausforderung, aber nicht für mich, da ich im Optiklabor damals ständig damit zu tun hatte.
Ich gebe zu, ich hatte einen aufwändigen Aufbau hingestellt, um die Lichtspiegelungen auszuschalten, aber wie gesagt, das war damals mein Job (Dunkelfeld, Hellfeld, Diffusor).
Schatten ließen sich trotzdem nicht ganz vermeiden, darum musste ich dennoch den abgebildeten Kommutator noch ausschneiden (wer errät, wie?).

So sieht das Kommutator-Bild nun seit vielen Jahren aus:

Kommutator

Kommutator als Beispiel für SEO in der Bildersuche.

Was aber hat das mit SEO zu tun?

Nun, das Foto hatte ich bewusst kommutator.jpg genannt, weil es einen solchen darstellte und zugleich in der damals noch von Vielen vernachlässigten Bildersuche bei dem Suchbegriff „Kommutator“ auftauchen sollte. So mein Gedanke.
Ja, und was soll ich sagen?
Google hat doch tatsächlich jahrelang mein Kommutatorbild als erstes Bild in den Suchergebnisseiten (SERPS) angezeigt.
Bei der Bildersuche war es meistens auf Platz 1, sogar Wikipedia und manch technische Erklärungsseite konnte dagegen abstinken, später sank es etwas nach unten.
Fein war auch, ich musste kaum etwas tun, sondern einfach nur die Zeit arbeiten lassen, weil Zeit auch für einen arbeitet. Google schien darauf zu vertrauen, dass wenn das Bild schon so lange da stand, es wohl auch so stimmen müsse, dass hier ein Kommutator zu finden sei.
Sicher, manche Besucher landeten auf meinem Blog in der Hoffnung, eine technische Erklärung zu einem Kommutator zu finden oder gar das Produkt selbst. Leider nein, obwohl ich hätte prinzipiell beides gekonnt haben können, dank meiner Elektrotechnischen Ausbildung und meines Diplom Ingenieur Titels, hätte ich wollen.
Aber: Nur Foto, nicht anfassen.

Das hat sich eines Tages geändert, wie ich feststellen musste, weil bis dahin habe ich dieses Kommutator-Foto gerne als Beispiel genommen, wie effektiv sprechende Dateinamen für die Optimierung bei der Bildersuche sind. Diesesmal war das anders, denn mit meinem Foto (!) wurde eine andere Seite verlinkt.
Ja, ich war raus und ein anderer drin.

Wie das?
Das exakt gleiche Foto in der gleichen Größe steht nun (Stand jetzt ) auf einer anderen Webseite und wird von Google wohl schon seither verlinkt bei der Suche nach „Kommutator“, anstelle von meinem schönen Bild.
Zum einen frage ich mich, warum macht der andere Seitenbetreiber das? Nur weil er Hersteller von Kommutatoren ist, hat er das Recht, mein Foto zu nehmen?
Oder war es ein Suchmaschinenoptimierer, der meine Seite gelesen hat und gedacht, da nimmt er gleich das Original?

Aber zum anderen Frage ich mich, warum macht Google das?
Weiß Google nicht, dass meine Seite und mein Foto erheblich älter ist das das was Oma Google nun neu verlinkt?
Gab es da nicht mal was mit doppeltem Content und so?
Wie funktioniert hier die sogenannte KI von Google, dass sie vom Ursprung des Bildes auf eine Kopie wechselt?
Ist es darum, weil auf der anderen Seite mehrere Kommutatoren abgebildet sind und bei mir nur dieser einer?
Würde Google dann auch eher auf eine Raubmordkopiererseite verlinken, weil dort z.B. mehr Blockbuster-Filme zu finden sind als auf der Urheberseite?
Ist es also so leicht, jemandem den guten Platz bei der Suche zu klauen, indem man ein Bild oder Text kopiert?
Wollte nicht Google genau dagegen vorgehen und seine KI verbessern?
Irgendwie erinnert mich das etwas an Schwarzhut-SEO.

Tatsache bleibt, richtige Benennung der Dateinamen wirkt, ob so oder so.
Darum habe ich mein Kommutatorfoto einfach kommutator.jpg genannt.
Mal sehen, wie Google darauf ragiert.
Denn eigentlich belohnen die doch obengenanntes nicht?

Wer helfen will, dass ich meinen Platz bei Oma Google wieder bekomme, kann gerne auf meine Seite mit „Kommutator“ verlinken.
Ein bisschen enttäuscht hat mich Google schon.

Veröffentlicht in Fotografien, Suchmaschinen und SEO | Getaggt , , | Hinterlasse einen Kommentar

Ruhig Blut bei Updates

Veröffentlicht am Samstag, 9 Mai, 2015 von Frank König

Neulich war es soweit, ein Update von WordPress mit fatalen Folgen für den einen oder anderen.
Das Gute ist des Besseren Feind, heißt ein Sprichwort, aber neu ist nicht automatisch besser oder gut.
Abgesehen von einigen Wenigen die ständig die neuesten Versionen testen müssen, gibt es für die Meisten wohl keinen Grund, gleich die neueste Version zu installieren. Denn genau genommen betätigt man sich damit als Betatester, wie auch im oben angemerkten Fall.
Und gerade bei Kundenprojekten kann man es sich eigentlich nicht leisten, ohne einen gewissen Abstand die Seiten der Kunden gleich auf die neueste Version upzudaten [schönes Wort]. Erfahrene Admins warten immer, bis sich eventuelle erste Fehler zeigen und diese ausgeräumt sind.

Das ist ein wenig so wie mit den Aktien, bei denen man die Füße still halten muss, wenn sie mal rauf und runter gehen.
Und WordPress hat das zudem schön eingerichtet mit den Sicherheitsupdates, die im Hintergrund automatisch laufen und auch etwas ältere Versionen versorgt. Zur Not greift man manuell ein und löscht, wie in diesem Fall, die benannte Datei aus dem Theme.

Inzwischen ist es so weit, dem WordPress Team kann man dabei vertrauen, gibt es nach sehr kurzer Zeit ein neues Update bei dem alle Fehler bereinigt sind und die Probleme nicht mehr auftauchen [zumindest bei mir nicht].
„Ruhig Blut bei Updates“ half auch hier, sich viel Arbeit und Nervengeld zu ersparen.

Veröffentlicht in CMS | Getaggt | Kommentare deaktiviert für Ruhig Blut bei Updates

Tipps für sichere Usernamen in WordPress

Veröffentlicht am Freitag, 21 Juni, 2013 von Frank König

Seit einiger Zeit werden WordPress-Seiten zum Teil sehr massiv mit Brute-Force Methoden angegriffen, um das Passwort „zu erraten“ für den Admin oder andere User.
Meistens laufen die Angriffe auf „admin“, weil das der erfolgversprechendste User in WordPress Installationen ist, denn erstens war „admin“ früher fest als Administrator-Login vorgeschrieben und zweitens handelt es sich dabei um einen User mit Administrator-Rechten (kann auch PHP-Dateien intern editieren, für Einbrecher also sehr interessant und bösen Code einzubauen) und drittens lassen auch viele den „admin“ als User stehen, obwohl WordPress seit einiger Zeit den Admin-Login bei der Installation frei ändern lässt.
Später kann man den Usernamen (Login-Name) nicht mehr ändern.

Das Problem mit dem Standard-Admin:

Es gibt immer wieder zu lesen, dass man doch bitte aus Sicherheitsgründen nicht mehr „admin“ oder „Admin“ also ersten Usernamen nehmen solle, sondern etwas anderes.
Für andere CMS mag das ja einen Sicherheitsgewinn ausmachen, aber nicht für WordPress, denn die Entwickler haben sich gedacht, man könne sich doch den Usernamen über das Web anzeigen lassen mit diesem Link: http://www.123-blog.de/?author=1

/?author=1 zeigt den URL-tauglichen Usernamen des Nutzers mit der ID=1 an, also immer der User, der bei der Installation als erstes eingetragen wird, nämlich der Administrator mit allen Rechten.
Man kann das Spielchen so fort führen indem man einfach alle Nummer durchprobiert und schaut, ob Antworten kommen, und tatsächlich fand ich in den Logfiles die Anfragen mit allen Nummern bis 99 durch die Angriffs-Programme (die Angreifer sind meistens automatische Programme).

Die Antwort vom WordPress-Programm sieht dann z.B. so aus: http://www.123-blog.de/author/admin
„Juchhu„, sagt sich das Angriffsprogramm, „ich hab den Usernamen!“ und tatsächlich stimmt es in den meisten Fällen auch, weil der Standard-Username eben „admin“ lautet.

Es mag durchaus Sinn gehabt haben, warum man so einfach den Login-Namen herausfinden kann, denn als WordPress noch jung war, war von solchen Angriffen wie sie heute statt finden, kaum die Rede und WordPress wollte vielleicht eine einfach Möglichkeit bieten, wie man automatisch den Autor herausfinden und auf alle Beiträge dieses Autors verlinken kann.
Inzwischen aber haben sich die Möglichkeiten für die Angreifer erheblich verbessert, dank der schnellen Datenleitungen und Server können die Angreifer tatsächlich einfach alle möglichen und unmöglichen Passwörter durchtesten beim Loginversuch mit dem User „admin“.
Steter Tropfen höhlt den Stein und irgendwann passt vielleicht zufällig ein Passwort und schon ist eine weitere WordPress-Seite gehackt, ganz automatisch und ohne Mühe für den Angreifer.

Der oft gelesene Ratschlag, den „admin“ zu löschen und einen neuen User einzutragen oder bei der Installation einen anderen Namen zu wählen, nützt meistens nichts. Warum?
Weil WordPress automatisch den gewählten Usernamen nimmt und daraus einen URL-tauglichen Namen erzeugt und in die Datenbank speichert. Somit kann das Angriffs-Programm ganz einfach mit dem Author-Link (der mit dem Fragezeichen) den Usernamen wieder heraus finden. Damit ist nicht wirklich viel gewonnen und man wägt sich in trügerischer Sicherheit.

Aber es gibt Unterschiede, die man nutzen kann:

Da WordPress einen URL-tauglichen Namen generiert, dürfen darin keine Sonderzeichen und keine Umlaute vorkommen. So könnte man doch auf den Gedanken kommen, den Usernamen „ädmin“ statt „admin“ zu wählen, mit einem ä am Anfang. Aber WordPress lässt für die Wahl des Usernamen keine solche Sonderzeichen zu, wir ahnen warum (soll ja URL-tauglich werden und hat vielleicht noch historische Gründe und wegen lokaler Unterschiede in der Tastatur usw.) Es wäre zu schön gewesen, hätte WordPress aus dem „ädmin“ einfach ein „admin“ gemacht. Auch z.B. ein # im Namen wird nicht akzeptiert.

Es gibt aber noch mehr, was man ausnützen kann, denn Großbuchstaben werden klein gemacht und Leerzeichen werden mit einem Bindestrich versehen. An dieser Stelle sei vermerkt, dass ein Leerzeichen im Usernamen alleine keine besondere Sicherheit darstellt, weil es für Programmierer leicht ist, beim Antreffen eines Bindestriches auf ein Leerzeichen im Login-Namen zu schließen und das entsprechend zu programmieren.
Aber eine Kombination aus beidem könnte doch deutlich mehr Sicherheit bringen:

  • KlausMaus wird zu klausmaus
  • Klaus Maus wird zu klaus-maus
  • klauS MauS wird auch zu klaus-maus

Wir sehen hier, dass man mit der Kombination von Groß- und Kleinschreibung an verschiedenen Stellen (und vielleicht noch mit Leerzeichen) durchaus einiges zu Rätseln für das Angriffs-Programm aufgibt. Alleine das zu knacken könnte schon dauern, je nachdem wie verschachtelt man das schreibt: KlaUsmAuS-zUhauS und das Angreifer-Programm dürfte alle möglichen Kombinationen durchprobieren müssen, bis der richtige Login-Name mal getroffen wäre.

Und nun stelle man sich das noch in Kombination mit einem langen und sicheren Passwort vor, mit Sonderzeichen, Zahlen, Groß-Kleinschrift. Das dürfte eigentlich kaum noch zu knacken sein, es sind vermutlich zu viele Kombinationen.
Das muss man dann aber für alle User so durchführen, denn es werden auch die anderen User gefunden und darauf angegriffen.

Und dann bitte nicht für den „Angezeigten Namen“ (display name) den original Login-Namen stehen lassen!! Sonst war alles umsonst.

Es geht aber noch besser:

(auf eigenes Risiko* für Datenbankversierte User)

Wer meinen Link oben ausprobiert hat, wird sehen, dass tatsächlich „admin“ angezeigt wird.
Bin ich etwa so leichtsinnig, und habe als Usernamen nur admin oder Admin gewählt?
Nein, bin ich nicht, es ist ein Honeypot (Honigtopf), extra für die lieben, dummen Angriffsprogramme so stehen gelassen.
Einem so leckeren Honigtopf können diese Programme gar nicht widerstehen, sind sie doch vornehmlich auf „admin“ getrimmt.
Was habe ich gemacht?

In der Datenbank gibt es in der Tabelle wp_users (man sollte hier durchaus bei der Installation auch einen anderen Präfix wählen statt „wp“) zweierlei Spalten für Login-Name und eben diese URL-taugliche Version.
In der Spalte user_login steht der tatsächliche Login-Name (Username) und in der Spalte user_nicename steht eben dieser URL-taugliche Name. Den trägt WordPress automatisch ein und den kann man nicht vom Backend aus ändern.
An dieser Stelle noch die Anmerkung: user_nicename ist nicht der Nickname, auch wenn es sich ähnlich liest, es ist eher ein Alias-Name für technische Dinge wie eben die URL.
Da WordPress seit einiger Zeit es ermöglicht, einen Nicknamen einzutragen, könnte man das miteinander verwechseln.
Aber zum einen taucht der Nickname, den man selbst wählen kann, gar nicht in dieser Tabelle auf, sondern in der Tabelle wp_usermeta.  Und zum anderen kann man diesen Namen mit Sonderzeichen und Umlauten verwenden.
Merke: user_nicename ist nicht Nickname.

Nun, da WordPress mir nicht ermöglicht, den user_nicename zu ändern, mache ich es einfach über die Datenbank, aber anders herum.

  1. Ich installiere WordPress mit Usernamen „admin“.
  2. Nach der Installation gehe ich in die Datenbank, und ändere direkt in der Tabelle den Usernamen in user_login (nicht den user_nicename) von „admin“ auf irgendwas anderes (was ich garantiert nicht verrate), ohne Sonderzeichen oder Umlaute.
  3. fertig

Das war’s, mehr ist nicht.
Kann man auch jederzeit nachträglich machen.
Für die dummen Angriffsprogramme bleibt der angezeigt Autor weiterhin „admin“ (was ungemein verlockend ist).
Wordpress scheint trotzdem ganz gut zu funktionieren, obwohl diese beiden Namen ganz unterschiedlich sind.
Und ich logge mich dann unter dem neuen Namen ein statt mit admin, und es funktioniert prächtig,
* (hoffentlich ändert das WordPress nicht irgendwann mal, aus „Sicherheitsgründen“ womöglich, denn dann könnte es schwer werden, sich noch einzuloggen).

Tatsächlich laufen bei mir immer noch täglich sehr viele Angriffe auf den Namen „admin“, aber die Chancen sind gleich Null, weil es einen „admin“ als User eben darum nicht gibt.
So oft ich auch die Login-Fehlversuchs-Statistik ansehe, es lautet fast immer auf „admin“. Tja, mit Honig fängt man nicht nur Fliegen, sondern auch Angriffs-Programme.
Um die Angriffe nicht ins Uferlose treiben zu lassen, habe ich zusätzlich noch ein Plugin installiert, das fehlerhafte Loginversuche begrenzt und eine Zeit lang sperrt. Trotzdem kommen noch täglich 20 bis 100 Sperrungsmeldungen (die Loginversuche sind also viel mehr).

Hatte ich schon erwähnt, dass das Passwort natürlich trotzdem sicher sein sollte?

Um die lästigen Loginversuche abzuwenden, könnte ich auch einfach noch das Admin-Verzeichnis mit Usernamen und Passwort sichern, mittels .htpasswd zum Beispiel. Dann müsste ich mich zwar immer zweimal einloggen um ins Backend zu kommen aber dafür kämen die Angreifer erst gar nicht mehr zum Login-Bereich. Das sei jedem geraten, der seine Seite sicherer haben will.
Ich tue es nur nicht, weil ich auf dem Laufenden sein will, was sich da so tut.

Veröffentlicht in Allgemein, Wordpress anpassen | Getaggt | 4 Kommentare

Was tun gegen die vielen Angriffe auf WordPress-Seiten?

Veröffentlicht am Dienstag, 28 Mai, 2013 von Frank König

Die Angriffe auf meinen Blog hier reißen nicht ab. Inzwischen nicht mehr nur am Wochenende, sondern jeden Tag die gleiche Leier. Anderen geht es aber auch so ähnlich, wie hier zu lesen ist: http://www.tagseoblog.de/hacker-angriff-auf-tagseoblog-und-was-ich-dabei-gelernt-habe
Inzwischen leite ich alle Benachrichtigungen (per Email) von Angriffen direkt in meinen Junkmail-Ordner. Die Löscherei ging mir auf die Nerven, aber ganz auf die Info was gerade läuft, wollte ich auch nicht verzichten.

Sergej Müller hat inzwischen einen aktuellen Artikel verfasst, was man gegen Angriffe auf die XML-RPC Schnittstelle von WordPress tun kann: http://cup.wpcoder.de/wordpress-xmlrpc-schutz/

Viele wissen vermutlich gar nicht, dass es diese Schnittstelle gibt und noch weniger, wie man sie abschalten könnte. Die Anleitungen von Sergej sind denn auch nicht für Laien gedacht und nicht jeder kann oder darf .htaccess Dateien einbinden. Manche schließen den Rest der Welt vielleicht aus und wundern sich über zu wenig Besuch. Interessant wäre hier vielleicht ein Plugin, das Angriffe auf diese Schnittstelle blockieren könnte.

Hier hat sich auch jemand ganz aktuell Gedanken über die Sicherheit bei WordPress-Seiten gemacht: http://www.netz-gaenger.de/blog/wordpress-tutorials/wordpress-security-masnahmen-erweitern

Man kann mit dieser Anleitung sicher einiges für die Sicherheit seines Blogs tun aber der Autor selbst hat schon erkannt, dass es auch Nachteile gibt.
Nämlich die, dass man zum Arbeiten wieder einiges ausschalten muss.
Das hört sich im ersten Moment noch nicht so wild an, aber tatsächlich blockieren die Sicherheitseinstellungen die Arbeit mit einer Webseite. Wenn man nicht nur eine Seite hat, sondern viele, und alle sind richtig aufwändig abgesichert, dann wird man irgendwann die Seite nicht mehr anrühren, weder etwas schreiben noch daran was ändern, weil es schlicht zu umständlich und aufwändig wurde.

Ich spüre die Umstände schon bei Hostern, die Besitzrechte des wwwrun oder phprun nicht mit dem User des Accounts gleichgeschaltet haben und man bei jeder winzigen Änderung per FTP an Dateien die Besitzrechte umschalten darf und nicht vergessen, wieder zurück schalten, sonst geht vieles WordPress nicht mehr, wie Updates und so. Da man sich dazu bei diesen Hostern einloggen muss, um die Besitzrechte zu schalten und jedesmal Gedenkminuten warten muss bis alles auf dem Server umgesetzt wurde, überlegt man es sich schon zweimal, ob man „wirklich“ etwas verändern muss oder ob es noch warten kann, bis sich genug angesammelt hat.
Schlimmer noch bei abgesicherten Rechenzentren mit zeitlich limmitiertem Account, einzig VPS Zugang zur Datenbank und WebDAV zum Webspace. Da überlegt man es sich seeeehr lange, ob man etwas machen muss.

Die Spontanität geht verloren.
Ohne Zweifel, man kann manches an Sicherheit gewinnen, aber man portiert sich intuitiv wieder zurück in die Steinzeit des WEB, zu rein statischen Seiten die einmal im Jahr eine Änderung erfahren.
Wo liegt die goldene Mitte?
Und auf WordPress zu verzichten ist auch eher unwahrscheinlich.

Veröffentlicht in Allgemein, Wordpress anpassen | Getaggt , , | Hinterlasse einen Kommentar