Code Modul php/html-Mix in einem Abschnitt

[evaki]

wb2.12.1 Code-modul Datei save.php ändern.

Code: [Select]

ln 39:  in /*    $notAllowedTags = array('<?php', '?>' , '<?', '<?='); */Modul in eine Seite einfügen und Beispielcode plazieren.

Code: [Select]

echo "<div>Noch im PHP-Modus!";
echo "<br>Mit abschließendem ?> nicht mehr, deshalb jetzt html folgend"; ?>
<p>haha, ich bin html. Nun mit einleitendem ?php wieder php-modus
<?php echo "<br>Wieder im PHP-Modus!</p></div>"; 
Die Erklärung für das Verhalten findet man hier funktion eval() Man kann also php ein- und ausschalten.
Viel Spaß mit dem Mixen.

MfG. Evaki
ps. Auch hier gilt wie beim ungepatchten Modul: Nur an vertrauenswürdige Anwender/Admins zur Benutzung freigeben.
Warum das??? Weil's bei uns gebraucht wurde.

[evaki]

Statt der Brachialmethode - hier zwar nur für den Test - eine Zeile zu entfernen, der nebenbei 'nen Variablen-Fehler (errorlog) auslöst, kann und sollte man das natürlich sauberer machen.

Statt nun ein separates Modul mit nur diesem Patch herauszugeben, wäre m.E. sinnvoll diesen aktuell anzuwenden, also etwas für die DEV.

An der Grundfunktion des Moduls ändert sich nichts. Es läßt nun auch die Möglichkeiten des Schaltens mittels eval() zu. Wer php-Code in's Modul einbringt, dem dürfte der Hinweis auf "unerlaubte" Tags genügen, braucht also niemanden, der ihm die Arbeit des Denkens abnimmt.

Das ist eigentlich ein exemplarischer Fall für Bequemlichkeit und Führung des Anwenders, wo dann nicht selten Beschränkung bei herauskommt. Bei den einen ungewollt und gut gemeint, bei anderen wiederum beabsichtigt - kennt man ja bei bekannten Firmen mit z.B. angeblichen Sicherheitsverbesse rungen.
MfG. Evaki

[evaki]

Bevor nun im vorhandenen Code-Module "gefummelt" wird, anbei codeX zum Ausprobieren, oder einfach drinlassen. Geändert wurde lediglich nur

Code: [Select]

ln 39: $notAllowedTags = array('<?php', '?>' , '<?', '<?=');
in
ln 39: $notAllowedTags = array('');

[evaki]

Code: [Select]

?>
 <style>media="screen"><!-- .codex { color: red; visibility: visible; } --></style>
<br><div>Ich bin nicht nur html, <br>sondern auch JS
<script>document.write ("<H4>Ich bin JS-generierter Text</H4>oder css.");</script>
<p class="codex";>Ich bin CSS-formatierter Text</p>
</div><br>
<?php echo "";  Man kann also auch ohne code2-Modul, und außerdem mixen.
Hatte ich mir lange schon gewünscht, aber erst die Anwender brachten mich drauf.

"Eigentlich" wollten die noch 'ne FE-CSS, aber warten erstmal die Erfahrungen ab, die sich sammeln werden.

MfG. Evaki

[evaki]

Ganz vergessen.
Diese Methode ist durchgehend in WB anwendbar, ob nun in Template, Modul oder sonstwo.
Weshalb es widersinnig ist, sie ausgerechnet im code-Modul zu auszusperren.

Mittlerweile ist auch geklärt woher die Anregung kam. Verückterweise wohl von mir selbst, als ich mal im Forum den Vorschlag machte die Modulinstallation mal "etwas freier" zu gestalten. Daraufhin wurde ein Weg gesucht und gefunden. Eigenen Anpassungen von Modulen wird von einigen Anwendern anscheinend zumindest bei der Installation die Auswahlmöglichkeit Abbrechen/Fortsetzen angeboten, inkl. Info. Bunt gestalten kann man es außerdem.
Was die so alles hinter meinem Rücken machen... 
MfG. Evaki

[dbs]

Code wurde vor 100 Jahren programmiert und ich denke mir, dass html nicht erlaubt werden sollte um u.a. auch kein Javascript da reinsetzen zu können. Wenn deine Änderung keine Fehler verursacht ist alles gut. Verantwortlich bist du ja eh selbst für deine Webseite.

[evaki]

Code wurde vor 100 Jahren programmiert

Es ist das aus      2.12.1
Es verursacht auch keine Fehler.
Na und was da ausgeführt werden sollte bleibt dem Anwender überlassen.
Es funktioniert ja wie immer, nur halt mit Umschaltemöglichkei t.
Code2 macht ja auch nix anderes, nur halt kein Mix.
Die Methode auf var eval() anzuwenden klappt überall in WB, und wird auch so angewandt.
Warum also nicht im Modul? Es ist jetzt ein Code For ALL (CFA) 
Zumal in der PHP-Doku diese Möglichkeit ausdrücklich erwähnt wird.
MfG. Evaki

[Luisehahne]

Werde mir das Code Modul für die kommende 2.13.0 WB Version vornehmen. Im Prinzip ist das richtig, was Evaki beschreibt.

Auf php.net heisst es:

Der Code darf nicht in öffnende und schließende PHP-Tags eingeschlossen sein, d.h. 'echo "Hi!";' muss anstelle von '<?php echo "Hi!"; ?>' übergeben werden.
Es ist dennoch möglich den PHP-Modus durch die entsprechenden PHP-Tags zu verlassen und wieder zu betreten, z.B. 'echo "Im PHP-Modus!"; ?>Im HTML-Modus!<?php echo "Wieder im PHP-Modus!";'.

Dietmar

[evaki]

Das hört sich doch gut an.
Hab' mal so allerlei durchgespielt, wo mir dann auffiel, daß 'ne FE-css schon sinnvoll wäre.
Damit die Darstellung reibungslos funktioniert, habe ich testweise ein CSS-Reset eingesetzt.
MfG. Evaki

[Gast]

So langsam wird WB wohl  ne Evaki-Edition.... vielleicht bleib ich besser bei 2.12.2 stehen

SEO meckert seit Jahren, wenn Dateien statt aus einer einzigen eben aus 25 Einzel-Files geladen wird. Systeme wie WP lesen sie ein und bauen daraus eine Einzelne.
Ich mag diese Geschichte mit den frontend.css so nicht, aber ich hab keine Lust, jedes Mal der Meckerarsch zu sein

[evaki]

FE-CSS muß man nicht, ist ja nicht zwingend.
Macht man ein Inline, so wie in meinem Test.
Ist auch nur ein Vorschlag, zur Erleichterung für die Anwender, mehr nicht.
Sogar wenn's implementiert wäre, bleibt's weiter die Entscheidung des Anwenders.
Genauso kannst natürlich bei Deinen Modulen überall die FE-CSS entfernen, wenn's Dir was bringt.

[dbs]

Kurz mal zum Meckern. Es ist natürlich absolut wichtig, dass Dinge, die nicht gut laufen, angesprochen werden.
Wenn man dann weiß was und warum es nicht gut ist, wirds leichter zu verstehen sein. Lösungsvorschläge sind auch gern gesehen.
"Meckern" wirds erst, wenn nur der Frust zu lesen ist. Wer hat da noch groß Lust sich drum zu kümmern. Deshalb zB mein Einwand wo das Konstruktive bleibt. Aber mich versteht eh keiner.

Das frontend.css Problem ist ja bei Snippets noch schlimmer. Sinnlos geladen obwohl nicht auf der Seite genutzt.
Leider ist Ruuds minify Lösung keine 1-Klick Lösung, weil jede Seite überprüft werden muss.

Meinen SEO Checker schrieb ich an warum die Bewertung immer noch so schlecht ist, obwohl nun bei mir HTTP/2 läuft und mehrere Dateien gleichzeitig geladen werden und kein Störfaktor mehr sein können. Antwort war, die Bewertung bleibt so, weil eine große Datei laden IMMER besser ist als mehrere kleine, auch wenn parallel. Pffff...

[evaki]

<offtopic>
SEO ist so wichtig wie 'ne TÜV-Plakette auf krumme EU-Gurken,
oder ein BIO-Siegel auf katholische Bananen - ja es ist Christi Himmelfahrt 
Zum Beispiel Ladezeiten und Verweildauer mit einzubeziehen ist mehr als schräg.
Wenn Google Sand in der Wüste verkauft, rennen wahrscheinlich auch alle hin, besonders im Sommerschlußverkauf .

Website: E = mc²
Hierbei werden - absehbar - so gut wie "alle" SEO-Forderungen nicht erfüllt. Schei.. der Einstein.
Per Ranking (+mehr) auf den Bildungstand zu schließen, hat aber schon was, so wie viel andere Verknüpfungen (Algorithmen) etwas über eine Gesellschaft aussagen können.

DE und EU haben es seit 1990 verschlafen, Suchmaschinen zu installieren. Einige Versuche gab's trotzdem in DE. Aber gute Ideen sind oft Perlen vor die Säue, zur falschen Zeit am falschen Ort, oder auch einfach mit dem falschen Konzept unterwegs. Sand in der Wüste zum Verkauf anzubieten, kann man sich erst ab einem bestimmten Machtfaktor leisten. Sowas kann man dann auch steuerlich abschreiben.
</offtopic>

[Gast]

SEO ist so wichtig wie 'ne TÜV-Plakette auf krumme EU-Gurken,

oder eine frontend.css für's Code-Modul

[evaki]

Is mir doch egal. Ich hab' keine Enkel.

[Gast]

Ich hab' keine Enkel.

Danke dafür....

Vielleicht sitzt du schon auf dem Bollerwagen seit um 7.00 Uhr, keine Ahnung, liest sich nur so.

Im Gegensatz zu anderen Page-Modulen wird es bei Code nie einen vorgefertigten Block geben, der vom System geliefert wird, vergleichbar mit News, wo es unterteilte Abschnitte im htt-Template gibt, eine Pagination usw. Von daher wäre auch ein möglicherweise verwendetes CSS immer auch individuell. Ich gehe davon aus, das ein Großteil derer, die Free-Code benutzen, dies im Code²-Modul tun werden, weil es mehr Möglichkeiten bietet. Ich hab auch nie verstanden, warum man in WB nicht schon vor Jahren das Code²-Modul zum Standard gemacht hat, ist aber eine andere Geschichte.
Es wäre also so, das eine möglicherweise eingebundene frontend.css zu 99,99% leer ist und da fehlt mir der Sinn. Es steht jedem frei, sich solch Datei anzulegen, diese als frontend.css oder frontendUser.css zu benennen und dann wird sie auch geladen, aber das wird nur der tun, der CSS dort benötigt.

Eine andere Geschichte wäre es, wenn man alle frontend.css oder frontendUser.css zusammenfasst und in einer Datei ausgibt (analog zu Wordpress). Dann würde eine Dummy-Datei, wie wir sie jetzt in verschiedenen Modulen haben, keine Rolle spielen. Die Technik zum finden, erkennen und unterscheiden dieser beiden möglichen CSS-Dateien ist vorhanden, man muß sie nur noch lesen und zusammenführen.

[evaki]

Es wäre also so, das eine möglicherweise eingebundene frontend.css zu 99,99% leer ist

Ja, da stimme ich Dir zu. Was ich bisher gesehen habe, waren nur einige wenige inline styles.
Ich sagte ja, warten wir die Erfahrungen mit dem Teil ab, zumal es nur wenige Fälle gibt, wo der Schalter sinnvoll ist.
Von der "schöneren Installation" - 'ne Demo - habe ich 'nen Screenshot, wobei ich nicht weiß, ob die mich auf den Arm nehmen wollen - weil die meine Art nachäffen -, oder ob das schon so in Gebrauch ist. (Siehe Anhang).
Kannst Du den Anhang nach'm Download löschen? Käme mir entgegen.
MfG. Evaki


edit: Anhang auf Wunsch entfernt (by dbs)

[Gast]

gesehen und für gut befunden 

ohne da jetzt groß rein zu schauen, sehe ich zwei Ansatzpunkte
- eine Zentrale Stelle im Module-Installer
- die install.php des jeweiligen Moduls

Weiß nicht, ob du da Zugang hast. Wenn es bei jedem Module Install so erscheint, (mit Abbruchmöglichkeit), ist es zentral.
Beides sollte m.E. kein Problem sein

Ich weiß nicht, wie man das früher gedacht hat. Ich könnte mir vorstellen: der Uwe will ja installieren, warum soll er an dieser Stelle eine Abbruchmöglichkeit haben?
Und die Beschreibung hat er sicher gerade da gelesen, wo er den Download gemacht hat.

Andererseits sehe ich aber rein vom Code her auch kein Problem, diesen Zwischenschritt einzubauen und macht man das zentral genau zwischen Einlesen der info.php und entpacken, geht auch auch spurenfrei

Kannst Du den Anhang nach'm Download löschen? Käme mir entgegen.

ICH kann das nicht, das dürfen nur die Admins

[evaki]

- eine Zentrale Stelle im Module-Installer
- die install.php des jeweiligen Moduls

Bei der Demo ist es noch im Modul. Ob auch schon zentral, weiß ich nicht.
Anscheinend haben die meine Ansätze von damals aufgegriffen. Ich schlug, soweit ich erinnere, vor, daß man ein Modul für die Module-Installation als Schnittstelle schafft, womit man dann freie Wahl in jeglicher Hinsicht hat, das Schnittstellenmodul richtet's ja. Da kann dann jede Initiative/Gruppe etc. ihre Spuren im jeweiligen Modul hinterlassen, also z.B. die Sache mit Hash für Dateien, oder Design oder...

Die haben mir aber noch immer nicht mitgeteilt, wohin das gehen soll, oder ob da  evtl. nur zu "Studienzwecken" gebastelt wird. Jedenfalls find' ich ganz hübsch zu sehen, was ich mal angezettelt habe, weil's auch zum WB-Aussehen paßt bzw. sich gut integrieren läßt.
MfG. Evaki

[dbs]

Weiß nicht ob relevant. Kostet vielleicht nur 1 Millisekunde.
Hier in der save Zeile 38

Code: [Select]

<?php if(isset($_POST['content'])) {
/* $notAllowedTags = array('<?php', '?>' , '<?', '<?='); */
    $notAllowedTags = array('');
    $content = (\str_replace($notAllowedTags, '', $_POST['content']));

Das Array machst du leer ( besser so: $notAllowedTags = []; )
Und dann ersetzt du leer mit leer in $_POST['content'].

Könntest also auch gleich $_POST['content'] verwenden:

Code: [Select]

<?php if(isset($_POST['content'])) {
   // $notAllowedTags = array('<?php', '?>' , '<?', '<?=');
   // $content = (\str_replace($notAllowedTags, '', $_POST['content']));
    $content = $_POST['content'];

[evaki]

Das wäre/ist wohl so konsequent. - Dafür, ob man nicht doch noch das ein oder andere Zeichen verbieten können sollte, fehlt mir der Über-/Durchblick, weshalb ich mich da nicht herangetraut habe. Wenn Du Dir aber sicher bist, sollte man das so machen. 

Habe mich ja erstmal über den "kleinen Patch" gefreut, da hiermit plötzlich so allerlei offen stand, was vorher nur umständlich oder garnicht ging.
Bei "uns" ist die Freude auch groß, da die mit meiner ursprünglichen Notlösung "Extra HTML-Editor", also parallel zum bestehenden, z.B. zwar Code unter <head> plazieren konnten, jetzt aber noch so allerlei anderes ermöglicht wird. Es wird also mehr über Möglichkeiten gesprochen, - eben Anwendersicht - als über Code-Optionen etc.

Stück für Stück wird's besser, und soweit ich DEV verstanden habe, könnte das (Core-Modul) in eine neue WB-Version einfließen. Bis dahin probieren wir halt noch ein wenig rum, und mehr... und freuen uns auch auf DEV-Kommentare.

ps. Bin auch neugierig darauf, wie andere WB-Anwender damit experimentieren, und natürlich darauf was bei den "hinten rauskommt". Es gibt ja nicht nur SimpleXML 
MfG. Evaki