Zielordner selbst definieren

[bega011]

Wunsch: Es wäre Klasse wenn man noch über die Kofiguration im Backend den Pfad – wo die css- oder js-Dateien abgespeichert werden – selbst definieren könnte (z.B. direkt in /assets/css oder assets/js anstatt immer in assets/addons/minify/cache).

[phoebusryan]

Wieso ist dies relevant? Schlussendlich ist es ein Cachefile und soll daher auch im Cacheordner liegen. Ziel ist es ja, dass man den Cacheordner jederzeit löschen kann, ohne, dass die Webseite Fehler schmeisst. Wenn du Cachefiles beliebig verteilen kannst, hast du dieses Feature nicht mehr.

[ynamite]

Ich fände dieses Feature ebenfalls gut. Ich bin nicht der Meinung, das ein kompiliertes CSS File ein Cache-File ist und eine CSS Datei gehört (meiner persönlicher Meinung nach) in den CSS Ordner. Ausserdem, wieso solltest du jemals diese CSS Datei löschen? Man kompiliert sie einfach neu oder verwendet ein klassisches, statisches CSS-File. Oder verpasse ich etwas?

[bega011]

Es wäre halt auch übersichtlicher – CSS-Dateien in den css-Ordner und JS-Dateien in den js-Ordner.

[alxndr-w]

Ich finde, dass das überhaupt nicht notwendig ist.

• Niemand soll diese generierte CSS-Datei je weiterverwenden oder bearbeiten.
• Die Dateien bekommen jedes Mal einen neuen Hash, wenn sich der Inhalt ändert.

Minify sollte die Hoheit darüber behalten und dementsprechend auch die Datei dort verwalten, wo Addons Cache-Dateien verwalten.

[ynamite]

@alexplusde

Sehe ich anders :) Es gibt nach wie vor genügend Entwickler die keine Precompiler etc. einsetzen. Wenn CSS und JS Dateien an logischen Stellen platziert werden, kann auch jemand der nie mit einem Precompiler gearbeitet hat, das CSS verändern. Das ist nicht nur kundenfreundlicher, sondern auch nachsichtiger.

Die Hoheit sollte meiner Ansicht nach der Entwickler haben, nicht das Addon. Das Addon sollte lediglich einen geeigneten Ort (Sache des Addon-Entwicklers) vorschlagen, nicht aber bestimmen.

Das mit dem Hash finde ich ohnehin unschön, aber das ist geschmackssache.

[phoebusryan]

Was interessiert es dich wie das Cachefile heisst und wo es liegt? Du wirst es nie verändern können. Wo deine originalen Files liegen, kannst du ja ohnehin selber entscheiden.

[alxndr-w]

Sorry, da muss ich nochmal intervenieren. Das ist keine Geschmackssache, sondern best practice: https://css-tricks.com/strategies-for-cache-busting-css/#article-header-id-2

Wenn du aus einem Precompiler generiertes CSS nachträglich bearbeitest, ist das mit dem Precompiling-Workflow hinüber. Dann brauchst du auch kein Minify mehr. Dann reicht's ja, wenn du es 1x installierst, das CSS generierst und danach das Addon mitsamt Quell-(S)CSS deinstallierst.

Spätestens beim erneuten generieren sind die manuellen Änderungen im generierten CSS wieder überschrieben. Wie das dann kundenfreundlich oder nachsichtig sein soll, möchte ich bitte erklärt bekommen.

Aber in deinem minify-Addon kannst du das ja machen, wie du möchtest :)

Mein Vorschlag wäre wontfix.

[ynamite]

@phoebusryan Was interessiert es dich, was mich interessiert? :) Hab gern die Kontrolle wohin ein Addon/CMS Daten speichert. Im Falle von JS/CSS fände ich es so schöner/logischer/besser.

Wieso sollte man das Cache-File (ich gehe davon aus, dass du vom generierten CSS sprichst) nicht verändern "können"? Das ich die Quelldateien hinlegen kann wo ich will ist mir bewusst und nicht der Grund für die Anregung.

@alexplusde danke für deine Intervention, aber ich rede nicht davon Cache-Busting nicht zu verwenden, nur ob man effektiv den Dateinamen verändern muss um das Caching zu verhindern. Muss man nicht, man kann beispielsweise auch einfach rewriten, so wie es SEO42 gemacht hat und wie ich es mit meinem Addon tue.

Mir ist klar, dass das nicht der Workflow sein sollte bzw. der Workflow dann im Eimer ist, aber in der Realität verhält es sich halt oft anders als in der Theorie. Allein in dem Büro wo ich arbeite, gibt es nach wie vor Entwickler die nicht mit Precompiler arbeiten (wollen) und die wollen nach wie vor direkt CSS Dateien anpassen. Ja, ist nicht effizient etc., aber so ist's nun mal.

Wir müssen hier auch gar keine Grundsatzdiskussionen führen, meine persönliche Meinung ist nur das CSS und JS Dateien an üblichen Stellen liegen sollten und nicht irgendwo im Cache-Ordner des jeweiligen CMS vergraben.

Ob das jetzt so umgesetzt wird spielt für mich nicht so eine gravierende Rolle und was ich mit meinem Addon mache, hat mit dem Thema sowieso nichts zu tun.

tl;dr Fix it or don't, persönlich fände ich mehr Kontrolle besser.

[skerbis]

Cache-File = Cache-File weil es es generiert und wieder gelöscht wird. Ist mir schnuppe wo es ist, Hauptsache in einem Cache-Ordner. Und auch aus SEO-Sicht vollkommen Wurscht. SEO-Dings hat so ziemlich alles falsch gemacht, so nebenbei. Entwickler haben gefälligst die zu kompilierenden Ausgangsfiles zu bearbeiten. Das lernen die dann auch.

[ynamite]

@skerbis sehe ich anders ... und was hat SEO damit zu tun? SEO42 hat so ziemlich alles falsch gemacht? Wow. Ok. Wie gesagt, macht's wie ihr möchtet, für mich hat die Diskussion damit ein Ende. Schönen Abend noch 👍

[phoebusryan]

Damit hat es sich erledigt.

[skerbis]

Du hast Seo-dings als erster erwähnt 😉@ynamite - vor allem was den Umgang mit CSS und js angeht - aber egal - mach dein Ding - bei seo*** war auf Verzeichnisebne nicht ersichtlich welches css man bearbeiten darf und welches das generierte ist - tja

[olien]

btw... eigene pfade fänd ich auch netter :-)

[tbaddade]

@phoebusryan heißt das, dass das kompilierte CSS weiterhin im Cache-Ordner landen wird?

[phoebusryan]

Ja genau - warum wollt ihr eigene Pfade? Warum wollt ihr Cachefiles woanders als im cacheordner?

[skerbis]

Cache ist perfekt / alternativ noch ein rewrite des folders für den der es schön haben will? Es darf definitiv nicht erlaubt sein den Quellfolder für die generierte CSS zu verwenden.(das Gegenstück zu DAU ist DAD)

[ynamite]

1. stammt das Issue bzw. der Wunsch, den Pfad anpassen zu können, nicht von mir. Ich find die Idee aber gut (das Addon wäre dadurch imo besser, weil es mehr Möglichkeiten bietet). Bin offenbar nicht der einzige.

2. hab ich SEO42 nur als Beispiel in Zusammenhang mit Cache-Busting erwähnt (eigentlich hat es mit der Diskussion herzlich wenig zu tun). Fakt ist, man könnte das mit dem Hash/Cache-Busting auch anders lösen.

3. hast du @skerbis geschrieben, dass das "SEO-Dings" eh fast alles falsch gemacht hätte. Krasses Statement, aus meiner Sicht kompletter Humbug und, noch viel wichtiger, für diese Diskussion total belanglos.

4. sehe ich noch immer nicht ein, wieso ein generiertes CSS File eine Cache-Datei sein soll bzw. im System-/Addon-Cache-Ordner liegen soll. Aber gemäss skerbis ist das ja "perfekt". Wenn das so ist, dann viel Spass bei der "Diskussion".

P.S. ich finde den Cache-Ordner alles andere als perfekt. Aber wie gesagt, enthalte mich jetzt. Hab irgendwie das Gefühl, dass das nicht erwünscht ist. So long ;)

[skerbis]

@ynamite sorry, kann seo42 einfach nicht mehr hören und sehen - hatte genug Stress damit, vielleicht war mein Statement dazu auch etwas zu emotional. Ein Rewrite des Folders würde Dir nicht helfen? Ich will auf Cache löschen klicken und sicher sein dass der generierte Scheiss verschwindet, daher ist Cache perfekt aus meiner Sicht. Und ja, sicher bist du erwünscht und Deine Meinung zum Thema.

[ynamite]

@skerbis schon gut, bin nicht sauer (und Pazifist), war nur verwundert über die Reaktion. Fair enough, alles gut ;)

Für mich gehört Frontend CSS einfach nicht zu Redaxo. Darum erwarte ich nicht, das der Cache-Löschen-Knopf auch die CSS-Datei löscht sondern nur Dinge die auch von Redaxo intern kommen.

Vielleicht liege ich ja falsch und die Mehrheit findet das aber so gut. Mich störts einfach (aber kann damit leben).

[skerbis]

🙏

[tbaddade]

Weshalb nicht ein input.text anbieten, wo man den Pfad manuell einstellen kann. Default kann ja der Cache-Ordner drin stehen. Wäre damit nicht allen hier geholfen?

[olien]

@phoebusryan Ich mag jetzt hier nicht mehr viel schreiben. Nur eine Antwort bin ich dir noch schuldig. Für mich ist der Grundgedanke von Redaxo, dass ich alles beeinflussen kann was im Frontend passiert. Dazu gehören auch Pfade :-))

LG Oliver

[phoebusryan]

Also gut, ich baue Textfelder ein womit man den Pfad definieren kann. Der Standard ist dann einfach das Cacheverzeichnis. Dann sind alle glücklich :)

[alxndr-w]

Danke @phoebusryan für deine Offenheit, Wünsche und Anregungen umzusetzen.

Selbst, wenn ich absolut hinter dem Nein gestanden hätte - es entspricht ja dem FOR-Gedanken, dass hier alle mitbestimmen können. Dass du's sogar selbst einbaust und nicht auf einen PR wartest, finde ich klasse.

[olien]

Respekt!!

[bega011]

THX! :)

[ynamite]

Danke!

[phoebusryan]

Done in Version 1.6.0

[alxndr-w]

War ja ne super Idee...

Setip: YRewrite, 2 Domains, Theme-Addon, beide SCSS-Dateien heißen styles.scss

Beim generieren der SCSS-Datei überschreiben die sich gegenseitig, sodass immer, wenn jemand Domain A besucht, das nächste Mal bei Domain B das falsche SCSS geladen wird und vice versa.

Die generierten SCSS-Dateien oder deren Pfade müssen bei Multidomains eindeutig benannt werden können, am besten in Abhängigkeit vom SET.

Das war an der vorigen Lösung von @phoebusryan mit dem Zufallsdateidamen eleganter und hat bei uns hier gerade für ein Riesenproblem gesorgt.

[phoebusryan]

ja.. unbedingt anders benennen. Gutes Beispiel. Hat aber sonst nichts mit mir zu tun oder? Warum hast du wieder geöffnet? :)

[alxndr-w]

Die generierten SCSS-Dateien oder deren Pfade müssen bei Multidomains eindeutig benannt werden können, am besten in Abhängigkeit vom SET.

Man könnte den Pfad pro SET einstellen / abweichend von der Standard-Konfiguration. Und ein Hinweis in der ReadMe oder beim entsprechenden SET fände ich auch empfehlenswert...

Das Problem fällt nämlich nicht auf, wenn man sich im dev-System nur auf einer Seite bewegt.

[phoebusryan]

Ah, das Problem bezieht sich also hauptsächlich auf die SCSS Dateien im Debugmodus oder?

[alxndr-w]

Ob's auch ohne Debug-Modus das Problem gibt, kann ich gerade nicht überprüfen. Mit auf jeden Fall...

edit: ohne Debug-Modus erhalte ich gerade nen 500er.

[phoebusryan]

Mit kann es eigentlich keine Konflikte geben, da er das SCSS nur kurz ablegt und dann direkt bundled. Das kompilierte File wäre danach überflüssig.

500er können grundsätzlich mit minify zusammenhängen. Zum Beispiel wenn das PHP Timeout zu kurz ist.

[phoebusryan]

Was ist daraus geworden? Wie das SCSS-File heisst, sollte komplett egal sein. Auch bei yrewrite mit mehreren Domains. Hauptsache der Setname ist unique.

Im Debugmodus verhält sich das natürlich anders, weil on the fly kompiliert wird. Das Problem hast du aber auch nur mit mehreren Domains, gleiche Dateinamen und aktivem Debugmodus auf mehreren Domains.

[alxndr-w]

Ich hab den Debug-Modus angelassen :(

[phoebusryan]

soll heissen? :)

[alxndr-w]

Ich muss den Debug-Modus zu einer unchristlichen Zeit ausschalten und dann hoffen, dass alles wie gedacht funktioniert. In Bezug auf den Kunden möchte ich da ungern nochmal eine fehlerbehaftete Seite zeigen oder nen 500er... der klickt da gefühlt alle 5 Minuten von morgens bis abends auf die eigene Website.

[alxndr-w]

Ist immer noch ein 500er, wenn ich den Debug-Modus ausschalte. Neues Issue?

[phoebusryan]

Ist das so? Ist mir soweit nicht bekannt. Der einzige mir erklährbare Grund ist das PHP Timelimit... wenn dies ausläuft. Wenn du mir ein 500er Issue machst, bringt mir das nicht so viel.. Es sei denn du hast die genaue Meldung in den Logs.

[alxndr-w]

Der 500er hat sich wohl mittlerweile gelöst, ist uns nicht mehr über den Weg gelaufen.