Beiträge

Hallo,

da Du keine PNs annimmst, stelle ich mal die Frage hier:
Werden auch Scans über DIN A4 bei Euch angeboten? Vielleicht sogar bis A0? Wäre ggf. für einen Kunden von mir interessant.

Grüße
Mozzi

Hallo,

bzgl. Abmahnfähigkeit würde ich es mal so sehen:
Wenn Du nicht genug Reserven hast, um im Zuge von erhaltenen Abmahnungen einfach mal die reale Rechtsprechung auszutesten, ist die Chance ziemlich groß, daß Du letztendlich auch dann zahlen wirst, wenn Du nur zu 40% davon ausgehst, auf dem juristischen Weg nicht drumrum kommen zu würden (oder so).
Und das wissen auch die Abmahnschw... .
Wenn Du dagegen aufgrund einer Sache abgemahnt wirst, die in einschlägigen Portalen als üblicherweise nicht abmahnfähig dargestellt wird, dann ist es recht wahrscheinlich, daß Du nur auf einigen Tagen Arbeitsausfall sitzenbleibst, aber nicht auch noch auf vielleicht knapp 1000 Euro Supportleistung für gestörte Persönlichkeiten sowie evtl. noch mehr Arbeitsausfall.

Übrigens ist es generell sinnvoll, Bilder tatsächlich auch in der Größe auf dem Server abzulegen, in der sie im Browser angezeigt werden, da die gängigen Browser derzeit kaum oder gar nicht auf brauchbare Schrumpfungsalgorithmen bei der Anzeige zurückgreifen. Probier mal den Unterschied aus zwischen einem hochwertigen Verkleinerungsvorgang (den z.B. IrfanView beherrscht - rein als Beispiel genannt) und der aktuellen Darstellung Deines Logos. Oder auch noch das Ganze mit aufgenommenen Bildern... sowas ist für viele eins der Merkmale, an denen man professionelle Webseiten von Amateurgebastel unterscheiden kann, wobei auch bezahlte Webseiten dabei nicht immer in der gewünschten Kategorie enden.

Grüße
Mozzi

Hallo,

also die Sache mit den HexCodes hatte ich eigentlich schon mal als Vor-vor-vor-Stufe zu Javascript-Lösungen vermittelt bekommen, angeblich wären Spambots schon lange darauf abgerichtet. Kann natürlich sein, daß das vorwiegend für Klartext- "mailto:"- Vorsätze gilt, also für Stellen wo nur die eigentliche Mailadresse codiert ist.
Aber es war auch schon zu lesen, daß verschiedene Robots bereits Javascript abarbeiten, und daß auch Spambots in diesem Bereich weiterentwickelt würden.
Aber wenn selbst auf der Mozilo-Seite mit der Kontaktmailadresse nichts kommt... erstaunlich, aber wohl aussagekräftig.

Bzgl. Javascript habe ich mittlerweile eher die Position bezogen, daß eine (Einstiegs-) Seite am besten außer einer Anmerkung gleich gar nichts mehr enthalten soll, wenn Javascript nicht läuft. Dann kann man sich wenigstens darauf verlassen, daß einige recht wichtige Javascript-Detailergebnisse auch beim Besucher ankommen, wenn der überhaupt so weit vordringt.
Wie z.B. eben die Mailadresse - oder man versteckt mit Javascript erfolgreich ganze Frames oder wichtige Links, die nicht über Google der entsprechenden verweisenden Seite zugeordnet werden sollen, z.B. weil sie die Suchergebnis-Reihenfolge nachteilig beeinflussen würden.
Oder z.B. bei einer Seite mit CSS-Aufklappmenü: Wenn dort bloß der IE mangels Ersatz-Javascript-Unterstützung streikt, hält man wohl eher die Seite für fehlerhaft und verschwindet wieder tatenlos, als wenn man nur eine Meldung bzgl. Javascript zu lesen bekommt und sonst nix.

Naja egal, ich verdrück mich dann mal

Grüße
Mozzi

Hallo,

da ich bzgl. Spam überdurchschnittlich allergisch bin, hatte ich mir aus Anlaß einer anklickbaren Mailadressenangabe eine Javascript-Erzeugung programmiert, die folgendes in der angegebenen Reihenfolge tut:
- Der mailto: -Anfang wird ganz normal als Variable gesetzt,
- es wird eine Wartezeit gestartet, die mittellange läuft und dann den mittleren Bereich der Mailadresse ergänzt,
- es wird eine Wartezeit gestartet, die lange läuft und dann den letzten Bereich der Mailadresse ergänzt,
- es wird eine Wartezeit gestartet, die schnell läuft und dann den Anfang der Mailadresse ergänzt.

Oder das Ganze mit noch mehr Schritten.
Erst am Ende des selben Javascripts wird die komplette Mailadresse in den HTML-Quelltext eingefügt. Die Zeitspanne vom Seitenaufruf bis zum Einfügen der Mailadresse beträgt 2 Sekunden, sicher geht es auch deutlich schneller.

Wie lange javascript-fähige Bots bei setTimeOut warten, oder ob sie sowas von vornherein unterschlagen, weiß ich nicht. Aber wenn ein Bot sowas tatsächlich abarbeitet, dann müßte er die TimeOut-Zeitangabe runterskalieren, um an die Mailadresse zu kommen. Und sowas halte ich für sehr unwahrscheinlich. Reines Abarbeiten wäre jedenfalls wohl zu uneffektiv für einen Spambot. Es sei denn, dabei ist schon berücksichtigt, daß TimeOuts nur recht selten auftreten, und der Bot hat entsprechende Puffer etc... ich hoffe aber stark, das ist nicht der Fall! ...

Um auf die Eingangsfrage zurückzukommen:
Mit diesem Ablauf wird ja letztlich per Javascript ein HTML-Inhalt aufgebaut, der kurz nach dem Seitenaufruf zur Verfügung steht und von aktuellen Spambots wohl kaum so erkannt werden kann.
Und das ist ja bei Weitem nicht nur auf Mailadressen anwendbar.

Ob man letztendlich auf diese Art ein ganzes Formularfeld aufbaut, oder ein bestimmtes Feld mit einem bestimmten Wert belegt, oder einfach nur die "Abschicken"-Taste von inaktiv auf aktiv umschaltet (als Bedienungshilfe im Fall von serverseitiger Reaktionszeit-Abfrage), ist ja eher zweitrangig; wichtig ist, daß der erzeugte Inhalt so gestückelt zur Verfügung gestellt wird, daß die relevanten Anteile vom Bot nicht erkannt werden. Wie z.B. eben ganze Domainnamen in Mailadressen, oder relevante Namen von Eingabefeldern in Formularen.

Für Mailadressen habe mir direkt ein kleines PHP-Skript gebastelt, das den Javascript-Quelltext nach Einlesen der Mailadresse erzeugt. Das ist ohne aufwendige Abwandlungen genauso auch für andere Zwecke verwendbar.

Grüße
Mozzi

Hallo,

es gibt aber schon noch ein paar mehr Variablen dieser Art, z.B. die die im Template verwendet werden - oder haben die andere Eigenschaften? Sicher sind einige davon sehr speziell, aber z.B. {LAYOUT_DIR} sollte doch genauso verarbeitet werden, oder?

Gibt es dazu eine wirklich vollständige Liste?

Grüße
Mozzi

Hallo,

ohne mich jetzt sonderlich gut mit apache auszukennen, aber vielleicht klappt das Folgende (wenn jemand was Gegenteiliges sicher weiß, möglichst gleich hier angeben):

Der Haken ist ja, daß verschiedene Benutzer im Spiel sind.
Also: Alles vom selben Benutzer erstellen lassen - soweit da nicht schon früher ein Riegel vorgeschoben wird:
Ein PHP-Skript hochladen per FTP, mit dem man wiederum Dateien hochladen und auf dem Server entzippen kann. Dann das ganze CMS gezippt hochladen und auf dem Server entzippen (hab ich mit nem eigenen Skript unter Verwendung des in Joomla enthaltenen kostenlosen Entzippungs- Skriptes aus http://www.phpconcept.net/pclzip/index.en.php gemacht, als ich mal Joomla ein bißchen durchtesten wollte - sonst dauert das Hochladen ja 30 Minuten pro Installation, mit Entzippen dagegen ca. 30 Sekunden!).
Damit sollte das ganze CMS dann dem selben Benutzer gehören. Und weitere unter Mozilo angelegte Dateien gehören ja sowieso dann dem selben Benutzer.

Wenn die Benutzerrechte zu stark eingeschränkt sind, könnte höchstens die Ausführung von per PHP hochgeladenen Skripten unterbunden sein - was aber wohl kaum Sinn machen würde. Oder sollten etwa die auf dem Server entzippten Dateien nicht vom www-Benutzer ausführbar sein? Naja dann wäre wohl sowieso dieser Webspace nicht sonderlich wertvoll...

Meint jemand, das geht nicht auf?

Grüße
Mozzi

[Ziel:]

Hallo,

hier nun auch von mir ein kleiner Beitrag für dieses nette CMS.

Es geht um die Möglichkeit, das Layout durch einen Admin beeinflussen zu lassen, der keine FTP-Rechte hat und sich nur mäßig mit Web-Sachen auskennt, aber einigermaßen logisch denken kann.

Anlaß war meine Überlegung, einem Bekannten für seine genialen Hobby-Ergebnisse eine eigene kleine Seite per Subdomain auf meinem Webspace anzubieten.
Aus früherer Erfahrung wollte ich dabei sicherstellen, daß ich die Wahlmöglichkeit behalte, statt langer Erklärungen kleine Layout-Wünsche von ihm schnell selbst umzusetzen oder ihm das später dann anhand der erstellten Vorlagen selbst zu überlassen.
Einen FTP-Zugang wollte ich ihm nicht überlassen, da auf dem Webspace auch meine geschäftliche Webseite und andere Daten von mir liegen.

Also nun endlich zur Lösung, die relativ einfach, aber dabei in meiner Umsetzung sehr flexibel ist:



Ziel:
Beeinflussung des Layouts durch Überschreiben von CSS-Einstellungen durch den Admin ermöglichen

Lösungsansatz:
Original-CSS-Datei beibehalten, zusätzliche CSS-Überschreibungen ermöglichen mit Hilfe von Dateien, auf die der Admin Zugriff hat.

Lösungsweg:
Zusätzliche CSS-Dateiaufrufe im Template,
- einmal für eine direkt vom Admin hochzuladende CSS-Datei mit vordefiniertem Pfad, und
- einmal für eine direkt vom Admin zu editierende versteckte Inhaltsdatei mit vordefiniertem Pfad, die von einem Mini-Skript ausgelesen und mit einem CSS-Header versehen wird.
Die aufgerufenen CSS-Dateien werden vom Browser generell in der Reihenfolge des Aufrufs ausgewertet, d.h. die originale CSS-Datei kann dabei durchaus komplett bestehenbleiben, soweit sie vor den anderen beiden aufgerufen wird.

Das war's eigentlich schon.



Umsetzung (Beispiel):


1. PHP-Skript "xget_css.php" im CMS-Hauptverzeichnis erstellen:

Code Auswählen Erweitern

<?php  // *****************************************  // Diese Datei fügt einer per GET  // angegebenen Datei einen CSS-Header hinzu.  // *****************************************  header('Content-type: text/css');  readfile($_GET['file']);?>



Dieses Skript ist nötig, um den korrekten CSS-Header zu erzwingen. Wenn direkt die versteckte Inhaltsdatei "kategorien/99_Website-Style/90_userstyle-css.hid" (s. weiter unten) eingebunden würde, würde z.B. Firefox diese wegen des falschen aufgrund der Dateiendung vom Server erzeugten Headers ignorieren.


2. Im Template zusätzliche CSS-Aufrufe hinzufügen (der @import-Befehl wurde aus anderen Gründen ersetzt):

Code Auswählen Erweitern

 <!-- <style type="text/css"> @import "layouts/{LAYOUT_DIR}/css/style.css"; </style> -->
  <link rel="stylesheet" type="text/css" href="layouts/{LAYOUT_DIR}/css/style.css" /><!-- Original-CSS-Datei -->
  <link rel="stylesheet" type="text/css" href="kategorien/99_Website-Style/dateien/userstyle.css" /><!-- Zusaetzliche Upload-CSS-Datei -->
  <link rel="stylesheet" type="text/css" href="xget_css.php?file=kategorien/99_Website-Style/90_userstyle-css.hid" /><!-- Uebergabe eines direkt editierbaren Dateiinhaltes als CSS-Datei -->

3. Layoutstil-Kategorie anlegen

Per Admin-Zugang die Kategorie "Website-Style" unter der Zählnummer 99 anlegen


4. Zusätzliche CSS-Inhalte und Bilder bereitstellen:
- Per Admin-Zugang die erste zusätzliche CSS-Datei mit den gewünschten CSS-Änderungen und -Ergänzungen mit dem Dateinamen "userstyle.css" in der Kategorie "Website-Style" hochladen
- Per Admin-Zugang die zweite zusätzliche Pseudo-CSS-Datei als versteckte Inhaltsdatei "userstyle-css" mit der Zählnummer 90 in der Kategorie "Website-Style" anlegen
- Per Admin-Zugang ggf. Bilder für Hintergrund, Logo etc. hochladen, entsprechend den eigenen CSS-Inhalten


5. Feddich.


Meiner Meinung nach ist gerade die 2. zusätzliche CSS-Einbindung eine gute Möglichkeit, schnell mal was auszuprobieren, ohne dabei ein Risiko bzgl. der regulären CSS-Inhalte einzugehen.
Wenn man dann noch 2 gleiche Tabs mit Inhaltseditor mit der jeweiligen CSS-Inhaltsdatei öffnet, bevor man auf dem ersten davon die Änderungen durchführt, kann man sogar auch auf mäßig besuchten produktiven Seiten schnell und unkompliziert mal etwas ändern und erst danach die reguläre CSS-Definition anpassen.


Wer es mal ausprobiert: Eine Rückmeldung würde mich freuen.

Grüße
Mozzi