parse_html_mode - wofür?

[update]

Wofür ist eigentlich

Code: Select all

$phpwcms['parse_html_mode']		= 'before'; // when to parse html: [null|before, after, before+after] frontend render

Denn meine Annahme, wofür es sein könnte, ist offenbar leider falsch...

[Oliver Georgi]

Es werden die BB Codes und weitere systeminterne Ersetzer geparst. Bisher erfolgte das immer bevor die Frontend Render Scripte ausgeführt wurden. Gelangen dort "frische" Ersetzer in den Content bleiben diese ungeparst bzw. man musste sich selbst drum kümmern. Mit diesem Setting kann das Verhalten geändert werden.

[update]

Danke für die Erläuterung
Ich hatte im Stillen gehofft, dass damit auch die container/row- wrapper (aus der default.conf) einsetzbar wären, während die Seite im Artikel/Contentpart-Listing-Mode aktiv ist (Stichwort "OnePager)...

[Oliver Georgi]

warum sollten die Container/Row Wrapper nicht nutzbar sein, wo ist das Problem? Aus meiner Sicht tun die genau was sie sollen. Die Gruppierung von Content Parts greift aber nur im Artikel-Detailmodus.

Artikel-Listing ist etwas anderes als ContentPart-Listing.

[update]

Die Gruppierung von Content Parts greift aber nur im Artikel-Detailmodus

Genau. Das ist mir klar (geworden).
Mit etwas Spucke und Tücke kann ich ja aber im Artikellisting auch die ContentParts listen (also ohne "more..."- Link) und da geht es leider nicht.
Ok, über den Umweg, mit zwei HTML-CPs ein paar CPs zu wrappen, geht es schon. Eleganter wäre gewesen, das ebenfalls mit dem Container/row-Feature machen zu können.
Also Onepager nicht aus mehreren Artikeln (übersichtlich), sondern aus einem einzigen Artikel bauen (schwierig beim Umsortieren)?
Sorry, dass ich (immer wieder|noch immer) so auf dem Thema rumreite, will es nur abschließend mal verstehen bzw. die optimale Version zur Hand haben

PS: Für das Umsortieren von gruppierten Elementen wäre ein Verschiebemechanismus wie zB beim CP imgspezial fein

[Oliver Georgi]

Ihr habt nicht verstanden, was ich in einem anderen Beitrag bereits grob umrissen habe. Das holen ALLER Inhalte im One Pager ist schlicht Unsinn. OnePager sind knapp und bündig. Und damit ist auch ALLES innerhalb EINES Artikels lösbar!

Wenn es dann komplexer wird, verteilt man es über mehrere Artikel und holt die Inhalt per Ajax. Dafür existiert alles im System. Das kombiniert man dann mit sowas hier: http://alvarotrigo.com/fullPage/

[breitsch]

Also Onepager nicht aus mehreren Artikeln (übersichtlich), sondern aus einem einzigen Artikel bauen (schwierig beim Umsortieren)?

na, na, irgendwie wär's ja schon schön sowas zu haben:

home (Startseite)
- Blumen (im prinzip wie ne OnePage Seite aus diversen Artikeln in dieser Seite)
. (Artikel) Rosen -> Ausgabe aller Cp's innerhalb <section>
. (Artikel) Lilien -> Ausgabe aller Cp's innerhalb <section>
. (Artikel) Dalien -> Ausgabe aller Cp's innerhalb <section>
.
- Kräuter (im prinzip wie ne OnePage Seite aus diversen Artikeln in dieser Seite)
. (Artikel) Minze -> Ausgabe aller Cp's innerhalb <section>
. (Artikel) Eisenkraut -> Ausgabe aller Cp's innerhalb <section>
. (Artikel) Salbei -> Ausgabe aller Cp's innerhalb <section>
.

Ein (fixes) Top Menu mit dem 1. Level und jeweils ein Artikelmenu das zu den (untereinander gerenderten) Artikeln/Sections scrollt

Damit (und nur damit, meines erachtens) kann man die einzelnen Artikel besser handhaben (ein-, ausschalten, schieben) und formatieren (Backgrounds seitenbreit oder Bildhintergründe usw.) mit einer CP Auflistung ist das - mind. komplizierter.

Claus, ist es das was du meinst/suchst?

Oliver hat schon recht wenn er sagt es sei alles dazu vorhanden, selbst ohne Ajax.
Ist aber etwas tricky das richtig hinzubekommen und das Zusammenspiel Menu/Artikelmenu/JS-Scroll zu orchestrieren.
Besteht Interesse?, resp. Claus schick mir mal PM oder direkt, du hast ja meine Email, deine Anforderungen, dann können wir das im Wiki erläutern.

[update]

Claus, ist es das was du meinst/suchst?

Ja, in etwa
Vor allem kommt es mir drauf an, kein Durcheinander zu haben und kein phpwcms-feature zu verlieren (Stichwort rendern von zB show_content, die Einsetzbarkeit von den in der default.conf definierbaren container/rows und selbstdefiniertes...).
Und es sollte bedienbar bleiben auch für eventuelle Kunden, also ohne Tricks und um die Ecke...
Die momentan aktiven OnePager-Varianten machen das schon prinzipiell/funktional, aber bei jeder fehlt entweder das eine oder das andere oder sonst was oder es bleibt unklar...
Ich schreib das mal zusammen und schick's Dir

[Old Boy]

Den Vorteil, alles in einem Artikel zu haben, halte ich bei OnePagern für sehr viel änderungsfreundlicher, als alles auf diverse Artikel verteilt zu haben!

Damit ich aber keinen unüberschaubaren Verhau an ContentParts erzeuge, bei dem das Verschieben nur eines CP ein Durcheinander verursacht, habe ich das so gemacht, dass ich als Layout zunächst 5-10 Customblocks erzeuge, {SECTION_01} ... {SECTION_10}

Die werden nun NICHT in der Haupt-Vorlage eingetragen!!! Und sind damit im FrontEnd zunächst garnicht sichtbar.

Nun fülle ich im einzigen vorhandenen Artikel die erforderlichen ContentParts wie gewünscht in die vorbereiteten Ablageorte {SECTION_01} ...

Damit die Inhalte nun auch im FrontEnd zu sehen bekomme, benötige ich lediglich noch im Ausgabebereich {CONTENT} z.B. einen CP "HTML", in dem ich die gewünschten CustomBlocks ( = Sections ) und deren Reihenfolge eintrage, nach dem Muster:

Code: Select all

{SECTION_01}
{SECTION_03}
{SECTION_04}
{SECTION_02}
{SECTION_05}
{SECTION_06}

Auf diese Weise kann ich die Gruppierung der Sections blitzschnell ändern.

Und die CP innerhalb der einzelnen SECTIONS ist nun auch deutlich überschaubarer, als zuvor.

Anstelle des CP "HTML" habe ich im nächsten Schritt nun den neu aus(f)gerüsteten CP "RegisterTabs" verwendet.

Dadurch erreiche ich gleichzeitig die noch schnellere Sortierbarkeit durch einfaches Verschieben und den unschätzbar praktischen Vorteil (für Ungeübte), nahezu beliebige Einstellung per "Häkchen Setzen" zufügen zu können, wie Background-Farbe oder Image, Schattenverlauf, Schriftfarbe und Typ, wasweissich...


Ich finde das sehr viel intuitiver als den Einbau von Scripts, was für einen Anfänger oder ungeübten phpwcms User sowieso viel zu suspekt ist und ein zu grosses Risiko darstellt, seine mühsam zusammengeschraubte Site gleich wieder zum Stillstand zu bringen!

Also... einen Versuch nach diesem Schnittmuster sollte man mal machen... ist ja nur eine Sache von Minuten

[update]

Bleibt aber immer noch die Frage nach der automagischen (bootstrapkompatiblen) Menügenerierung...

[pepe]

Da hast du wohl recht, aber das ist ein ganz anders Ding...

Wenn alles "vollautomatisch" wäre, bliebe ja keine Luft mehr, was Eigenes zu machen und alle Seiten sähen identisch aus... sturzlangweilig, oder?

Mit wäre viel lieber, wenn wir endlich ein 100% ausgeklügeltes multilinguale-System hätten... sonst ist es mit Europa noch eher aus...
OnePage sind im kommenden Jahr schon lange "Schnee von Gestern", du wirst sehen!

[breitsch]

Bleibt aber immer noch die Frage nach der automagischen (bootstrapkompatiblen) Menügenerierung...

ja genau

OnePage sind im kommenden Jahr schon lange "Schnee von Gestern", du wirst sehen!

tja mag sein, aber bis dahin will ich eben OnePage Seiten bauen können und zwar so 'vollautomatisch' wie möglich, resp. so, dass ein Laie die auch bedienen kann.

Ich finde das sehr viel intuitiver als den Einbau von Scripts...

Ist ja auch gut so, wirklich.
Wenn ich an meine Kunden denke, dann möchte ich aber WYSIWYG; was im BE zuoberst steht, steht auch zuoberst auf der Seite, grün gleich sichtbar, rot nicht, H1-H6 Reihenfolge einigermassen ohne daran zu denken richtig im FE, temporäres ein- und ausschalten so wie im BE eingetragen; wenn ich (als Laie) nach einem halben Jahr BE-Abstinenz eine neue Blume mit Bildern und Text und vielleicht noch einer Liste auf meiner Seite haben will was mach ich? Mir überlegen welcher Customblock noch frei ist, dann daran denken dass ich zuerst einen H1 Titel will (also CP-HTML), daran denken dass ich den Menueintrag hinzufüge. Oder einen neuen Artikel hinzufügen, meine CP's erfassen, vielleicht die neue Blume noch zuoberst raufschieben, und dabei bemerken, dass der Lilien-Artikel ja gar nicht mehr angezeigt werden soll - also das Artikelauge rot machen und fertig, im Frontend wird's genau so angezeigt, das Menu aktuell, HTML einigermassen valide. Das ist mein Ziel.
Wenn ich als Webmaster die Seite unterhalte - kein Problem, dann ist deine Version u.U. sogar die bessere, aber sonst???

Was ich eigentlich sagen will:
PHPWCMS kann ja alles, auch OnePage, es ist nur so grässlich gut versteckt wie man's macht und darum würd ich gerne eine funktionierende Lösung ins Wiki schreiben wo es vielleicht auch gefunden wird und nebenbei meine Lösung abgleichen mit den Anforderungen eines Anderen, der, so scheint's mir, in der gleichen Richtung arbeitet. Wenn ich aber im Wiki schon auf eure zahlreichen Tutorials zu OnePage stosse, tja, dann ist's ja alles super, mein Tag gerettet und das Internet um eine PHPWCMS-OnePage Seite reicher, auch auf die Gefahr hin damit altmodisch zu wirken, gell Pepe

[Old Boy]

Ich bin überzeugt, jede EINFACHE Lösung wird - natürlich auch von mir - gerne akzeptiert...
je einfacher und automatischer, umso besser

phpwcms war einmal - zu Beginn der Entwicklung - ein absolut intuitives CMS, was auch von Anfängern schnell erfasst werden konnte.
Selbst die Navigation war fix und fertig ... damit liess sich trefflich arbeiten. Selbst CSS braucht man eigentlich nicht zu beherrschen.
Die Möglichkeiten waren begrenzt aber überschaubar. Für Neueinsteiger ideal!

Bis heute hat sich so viel getan unter der Haube, die Möglichkeiten immens erweitert, dass es "fürchterlich" ist, den Einstieg zu finden.
Vieles muss man mühsam suchen, nachfragen, experimentieren. Machbar ist mittlerweile ja "fast" alles, nur niemand weiss, wo alles versteckt ist und wie man es zusammenschieben muss.
Selbst wenn man von der ersten Stunde an dabei war, fällt es schwer, den ständigen Änderungen zu folgen.
Selbst die Umbenennung von jahrelang verwendeten Standard-Klassen kann immense Arbeit machen, wenn Updates durchgeführt wurden... hätte man bloss nie diese Klassen selber auch verwendet
Natürlich ist das schnell gemacht, wenn es um nur eine einzige Site geht, ansonsten ...
So ist es nun mal, wenn alles im Fluss ist.

Man muss damit leben... ich lebe damit auf meine Weise und versuche, mich mit Bordmitteln zu behelfen, wenn es darum geht, eine / meine Lösung SCHNELL zu finden.
Ja klar, geniale Lösungen sind natürlich schön... dauern aber auch i.A. erheblich länger!
Wie oft habe ich hier im Forum schon Leute in etlichen Beiträgen und PNs um programmtechnische Lösung diskutieren sehen, wo eine schnelle Änderung von Hand in 10 Minuten erledigt gewesen wäre( Beispiel: Umlaute nach Update bei 20 Kategorietiteln austauschen!)

Mir ist i.A. klar, dass es oft besser/eleganter gehen muss, aber wo steckt die Lösung?
Da müssen 100 User 100fach nach ihrem Weg suchen, ein betriebswirtschaftlicher Wahnsinn!
Grund ist eine fehlende, aber unbedingt notwendige "offizielle phpwcms Musterseite", auf der alle integrierten Features ContentParts und Ersetze am leicht verständlichen Beispiel gezeigt werden.
Die gibt es nicht und wird es wohl auch nie geben. Tja, wenn die Zeit fehlt...

Umso ehrenvoller und ganz besonders für die neuen phpwcms User hilfreicher ist natürlich, dein Bemühen um nahezu automatische Lösungen mit den Mitteln, die unter der Haube versteckt sind.
Ich bin auf jeden Fall gespannt, was daraus wird, denn wenn ich auch persönlich die OnePager als suboptimal empfinde, so sind sie natürlich top aktuell und man kommt darum z.Z. nicht herum, will man ein paar Euros damit verdienen oder seiner Site ein ebensolches Image verleihen.

Auf jeden Fall werde ich deine Lösung nach der Veröffentlichung gerne und kurzfristig vesuchen, denn ich hab's immer schon gerne einfach gehabt. Und keine Sorge, Geld verdienen werde ich damit garantiert nicht! Für mich ist und bleibt phpwcms ein reines Hobby!

Da du meine Kommentare sehr gerne falsch verstehst, hier noch einmal in Kurzform:
Deine Idee finde ich SUPER, wenn du die die Mühe machen willst, denn:
Eine "bessere" (automatische) Lösung ist immer Feind der praktikablen (zusammengefrickelten)!
Ich bin gespannt!

[update]

Und wie ging das mit den Register(Tabs) => OnePager?

[Old Boy]

Ja PRIMA, ging das mit den Register (Tabs) und ohne viel zu überlegen... irgendwie voll "altersgerecht"

Die Beschreibung wird erweitert, sobald das "neue Knie" 100%ig funktioniert und ich aus der ReHa zurück bin
http://bootstrap.pepes-sandbox.de/onepa ... eln-2.html

Auf dem ausgeliehenen iPad treff' ich die "Tasten" nicht so gut und muss endlos korrigieren, dann geht der Blutdruck wieder zu hoch

Ob's aber überhaupt noch jemanden interessiert, wenn erst eure "Automatik-Lösung" am Start ist ???
Aber egal, irgendwie muss man die viele Freizeit ja totschlagen

Aber jetzt geht's erst mal zum "Wassertreten"