Die Variable $edit_preview in front_content.php

[xmurrix]

Hallo zusammen,

weis jemand von euch, was genau der Zweck der Variablen $edit_preview in der front_content.php ist?

Genauer betrifft es den kompletten Codeabschnit, in der die Variable gesetzt wird. Soweit ich das verstanden habe, wird hierbei eine Liste mit Artikeln einer Kategorie erstellt. Wird der Inhalt der Variablen irgendwo in den Sourcen verwendet?

Die Suche nach $edit_preview in der DB (con_mod, con_actions) sowie in den Sourcen hat keine Ergebnisse geliefert. Oder ist die Verwendung in kommenden Versionen geplant?

Grüße
xmurrix

[emergence]

ähm der code ist urgestein...
tauchte das erstmal in der 4.3 version auf... und wurde seit dem eigentlich nirgendwo mehr benutzt...

[xmurrix]

ähm der code ist urgestein...
tauchte das erstmal in der 4.3 version auf... und wurde seit dem eigentlich nirgendwo mehr benutzt...

Gibt es schon jemanden, der sich mit der front_content.php befasst?
Falls nicht, in wie weit kann man sich an der Entwicklung von Contenido mit beteiligen?

Ich erkläre mich gerne bereit, an der front_content.php oder hier und da mitzuwirken, wenn dies möglich ist.

Gruß
xmurrix

[HerrB]

Öhm... gibt es da so viel? Aber mach' doch einfach mal einen Vorschlag.

Bedenke jedoch immer, dass es soweit es irgend geht kompatibel bleiben muss. Ich empfehle Dir auch, mit der front_content.php aus dem Snapshot (http://www.contenido.org/snapshots) anzufangen und - optional - die Berücksichtigung von steses modrewrite-Package ist auch nicht ganz ungünstig...

Gruß
HerrB

[emergence]

Gibt es schon jemanden, der sich mit der front_content.php befasst?
Falls nicht, in wie weit kann man sich an der Entwicklung von Contenido mit beteiligen?

nur mit der front_content.php ? ähm keine ahnung um ganz ehrlich zu sein... beschäftigt hab ich mich schon so ziemlich mit allem was im cms zu finden ist...
betreffend entwicklung
hmm... so weit man selbst bereit ist zu gehen...

ich hab mich größteils auf bugfixes oder patches festgelegt und schau die meiste zeit dass, das vorhande halbwegs fehlerfrei läuft...

ich würd mal sagen
verbesserungsvorschläge, erweiterungen oder bugfixes werden im normalfall dann ins core system aufgenommen,
wenn sie seitens 4fb getestet,
halbwegs universell einsetzbar,
und zusätzlich auch noch kompatibel bei upgrades sind...

für detailierte auskünfte muss du dich aber direkt an 4fb wenden...

[xmurrix]

Öhm... gibt es da so viel? Aber mach' doch einfach mal einen Vorschlag.

Ich glaube, man kann sich immer Arbeit anschaffen. Ich denke schon, dass es noch Potenzial zur Weiterentwicklung/Optiomierung an der front_content.php (auch anderweitig) gibt.

Zuerst würde ich mal die Altlasten aus der front_content.php rausnehmen, z. B. die Geschichte mit $edit_preview, die ja laut emergence seit der Version 4.3 drin ist, aber keine Verwendung findet. Dann werden z. B. so oft Abfragen auf die Tabellen con_art, con_artlang, con_cat, con_catart, usw. durchgeführt, die eigentlich überflüssig wären, wenn Instanzen von entsprechenden Objekten (cApiArticle, cApiArticleLanguage, cApiCategory, cApiCategoryArticle) zu erstellen und auf die Eigenschaften der entsprechenden Objekte zuzugreifen. Dies hätte den Vorteil, dass man bei der Modulentwicklung auf diese Objekt-Instanzen zugreifen könnte.

Code: Alles auswählen

Bedenke jedoch immer, dass es soweit es irgend geht kompatibel bleiben muss.

Meinst Du damit Kompatibel mit den Sourcen aus 4.6.8.x er Versionen oder Abwärtskompatibel?

Code: Alles auswählen

Ich empfehle Dir auch, mit der front_content.php aus dem Snapshot (http://www.contenido.org/snapshots) anzufangen und - optional - die Berücksichtigung von steses modrewrite-Package ist auch nicht ganz ungünstig... :wink:

Danke für den Hinweis, aber gibt es nicht die Möglichkeit, nur an der Version von stese zu arbeiten, anstatt an Beiden?

Gruß
xmurrix

[HerrB]

Meinst Du damit Kompatibel mit den Sourcen aus 4.6.8.x er Versionen oder Abwärtskompatibel?

Nein, schwieriger: Kompatibel mit bestehenden Projekten auf V4.6.x-Basis.

Danke für den Hinweis, aber gibt es nicht die Möglichkeit, nur an der Version von stese zu arbeiten, anstatt an Beiden?

Nein, da stese von V4.6.8.5 ausgeht und der Snapshot so ungefähr bei V4.6.8.15 ist - die vorhandenen Änderungen sind nicht groß, jedoch sollte man beide einbeziehen (da es sicherlich auch sein kann, dass man versucht, stese's Ansatz aufzunehmen und dann ist das on top).

Dann werden z. B. so oft Abfragen auf die Tabellen con_art, con_artlang, con_cat, con_catart, usw. durchgeführt, die eigentlich überflüssig wären, wenn Instanzen von entsprechenden Objekten (cApiArticle, cApiArticleLanguage, cApiCategory, cApiCategoryArticle)

Für die front_content ist IMHO primäres Ziel die Performance und möglichst wenig Speicherverbrauch, da alles über diese Datei läuft. Eine simple Abfrage dürfte dabei a) schneller und b) "billiger" sein, als die Einbindung von ganzen Objekten (die vielleicht ansonsten gar nicht gebraucht werden). Das muss man testen und abwägen...

Gruß
HerrB

[stese]

Also prinzipiell bin ich sehr daran interessiert, das ModRewrite bundle standardisiert mit in den Core aufzunehmen, da es ziemlich aufwendig ist, jedesmal das aktuelle CMS anzupassen. Wenn das gewünscht ist, baue ich anhand der CSV Version und unter Beachtung der Core Namensräume das in die CSV mit ein und greife euch dort mit unter die Arme ... Müsste halt mit f4b abgeklärt werden.

[HerrB]

Da bin ich ja gerade dran... Bisher wollte ich das anhand Deines Bundles bewerten, alle Änderungen sind ja mit stese beschriftet.

Gruß
HerrB

[xmurrix]

Für die front_content ist IMHO primäres Ziel die Performance und möglichst wenig Speicherverbrauch, da alles über diese Datei läuft. Eine simple Abfrage dürfte dabei a) schneller und b) "billiger" sein, als die Einbindung von ganzen Objekten (die vielleicht ansonsten gar nicht gebraucht werden). Das muss man testen und abwägen...

Das ist auch ein wichtiges Kriterium, da ich ja schon testweise mit Änderungen an der front_content.php angefangen habe, werde ich mal das Resultat testen. Es bringt nichts, wenn die Verwendung von Objekten die Performance runterzieht oder den Speicherverbrauch erhöht.

Mir ist noch aufgefallen, dass die front_content.php im Mandantenverzeichnis mittlerweile nicht mehr vom Backend aus aufgerufen wird. Dafür gibt es die front_content.php im Ordner "contenido/external/backendedit/". Soweit ich das verstanden habe, wird im Backend nur die front_conten.php aus dem backendedit Ordner verwendet - oder habe ich was übersehen?
Falls es so ist, kann die front_content.php aus dem Mandantenverzeichnis doch bereinigt werden. Bringt zwar keine Performance, aber entschlackt den Code.

Gruß
xmurrix

[xmurrix]

Hallo zusammen,

habe meine Drohung war gemacht und testhalber die front_content.php aus dem Mandantenverzeichnis einem Redesign unterzogen.
Als Basis wurde die front_content.php aus contenido-cvs-2006-07-14 verwendet.

Folgende Änderungen wurden am Script durchgeführt:
- Verwendung von cApi*/cApi*Collection Klassen anstatt SQL-Statements und im Core vorhandener Funktionen.
- Bereinigen von nicht benötigten Code-Segmenten. Hier ist unter anderem alles raus, was mit $contenido zu tun hat.
(Für das Backend gibt es eine eigene front_content.php)

Das Resultat bei meinen Tests war eine ca. 15% ige Einbuße der Performance und natürlich mehr Speicherverbrauch aufgrund von neuen Variablen und einigen zusätzlichen includes.
Dafür ist der Code um einiges entschackt und die Redundanz ist minimiert.

Neu hinzu gekommen ist die Datei "class.code.php" in "/contenido/classes/contenido/" mit den Klassen cApiCodeCollection und cApiCode alá bisherige cApi-Implementationen.

Na ja, ihr könnt euch das ja mal anschauen und das Ganze auseinander nehmen. Vielleich ist hier und da was brauchbares dabei.

Download:
Redesign front_content.php

Grüße
xmurrix