Thema: Site jetzt richtig planen, wenn Anfang- Entwicklung

Hallo Ubuntuianer

Yeah...

Frag doch mal deinen Kunden ob er warten möchte..
oder ob er eine migration in 1.6 bezahlen würde..

Vielleicht ist ja doch Zeit Geld

Ich warte

Zitat von Ria

Ich möchte wissen wie geht der Profi jetzt ernsthaft vor, etwas genauer?

Gruss Ria

Abwarten, und nicht gleich auf den ersten Zug springen.

Sollte mal die stable erscheinen, einfach mal ein paar Bug-Fixes und Sicherheits-Updates abwarten...... so bis 1.6.15 ... Etwa ende 2011 oder so

ok, das war jetzt etwas sarkastisch.

Interessantreweise ist ja die Version Joomla! 1.0 bei Version 15. Dann war schluss.

Nun haben wir bei 1.5 auch die 15. Ausgabe und die ist sehr gut, stabil und sicher wie mir scheint.

Glaube kaum, dass es noch eine 1.5.16 gibt......... wobei ich nicht darauf wetten würde

Zitat von Joe Sixpack

... so bis 1.6.15 ... Etwa ende 2011 oder so
ok, das war jetzt etwas sarkastisch.

aber gar nicht so verkehrt ;-)
An der magischen 15 würd ich mich jedoch nicht verbeissen, ich erwarte mindestens noch ein Weihnachts- oder Neujahrs-Update Im SVN hat's seit der .15 noch geringfügig gewackelt.
19.12.2007 == J! RC4 + 24 Monate ~ 1.6alpha + 6 Monate = 1.6.0
Geschätzter 1.5.x EOL-Support ca. Ende 2012 (nach dem Weltuntergang) oder Anfang 2013

Ich setz mir mal eigenmächtig die Profi-Kappe auf und prognostiziere so ins Blaue hinein, anhand dessen was so in den letzten GHOPs für die 1.6er erfunden werden sollte und was die SVN-Version andeutet...

Zum Eingewöhnen am Besten die SVN-Version ziehen und nach Lust und Zeit updaten, um zu gucken was neu ist, sich geändert wurde oder wieder verschwunden ist :-) Seit der Download-Alpha ist wieder einiges passiert -- so wie damals zwischen den offiziellen 1.5er-Betas und sogar den RCs.
Auf die finale Optik oder Funktionsweise des Admin würd ich mich nicht verlassen: dort tanz der Bär. Da zur Qualitätssicherung jedoch nun endlich, endlich, endlich auch UnitTests gehören, sollten fatale Funktionsfehler oder GAUe minimal bleiben -- sofern die TestCases was taugen

Fietschas aka Extensions
"Content Types" ... ein CCK für Arme, die Luxus-Artikelkomponente -- war mal im SVN ;-) Schade, schade. Ob aus politischen oder technischen Gründen: der GHOP-Erguss ist nicht mehr im /trunk *). Vermutlich auch keine Konkurrenz zu echten CCKs wie K2 oder Sobi geworden.
Kontakte werden aufgebohrt und erhalten benutzerdefinierte Felder, was die ein oder andere "Social Extension", zusammengehackte Community-Module oder manch Kontaktformular-Komponente zukünftig überflüsig machen könnte. CB wird davon sicher nicht beeinflusst und fett und stolz irgendwann als CB3 aufschlagen.
Benuterverwaltung aka ACL. Endlich! Hat ja auch peinlich lange genug gedauert. Ausser dem Core wird aber erstmal kein CMP die neue Sicherheit nutzen. Die Neuerungen werden zur Folge haben, dass sich viele das System entweder totkonfigurieren oder zum Scheunentor aufsprengen weil sie die Prinzipien nicht raffen. Happy Support Time!! :-) Jede Joomla-Agentur kann sich dann auch Website-Wiederherstellung ins Portfolio schreiben <hehe>
Der Installer könnte am Ende endlich so clever sein und Updates nativ unterstützen statt stets dummdoof alles zu löschen samt erstellter Inhalte. Alle Erweiterungen die das jetzt schon "können" kochen bislang ihre eigenen Suppen.
Geplant waren auch Abhängigkeitsprüfungen und das JED könnte-sollte-müsste für (verifizierte) Auto-Update-Checks in irgendeiner Form "integriert" werden. Das hätte den Vorteil, dass nicht jede 2. Extension unkontrollierbar nach Hause telefoniert und den Admin ausbremst.

Und das wars dann aber schon mit Neuem zum anfassen im Core.

Rückwärtskompatibilität
100% native 1.5er die somit auch ohne Eigenschnickschnack am Framework vorbeiarbeiten sollten laufen. Jeder individuelle SQL-String gegen eine Core-Tabelle kann hingegen krachen. Einen neuer "1.5 Legacy-Layer" der u.a. auch die Fehler im Namenskonzept des 1.5er Frameworks ausbügeln muss wird Frieden stiften.
1.0er oder Mambo-Code ist also endgültig tot -- obgleich heute immernoch einige 1.5er-Pseudo-Natives einfach das Codechaos von Mambo/J!1.0 in ihren Startroutinen nachbauen, damit sie am eigenen Codewust nix ändern müssen. Faulheit siegt, ebenso der Wille irgendwie mit der selben Codebase noch Mambo 4.x zu unterstützen (freiwillig oder gezwungen.)

Probleme könnten die neuen ACL und deren aufgebohrte Struktur und API machen wenn "hartkodierte" Gruppen- oder, Nutzernamen sowie IDs wie die magische Admin #62 blindlings vorausgesetzt werden.
Es wird sicher eine ganze Weile dauern, bis sich portierte 1.5-er Erweiterungen mit 1.6-nativ prahlen nachdem sie sich daran gewöhnt haben, die ACL mal wirklich gegenzuprüfen um die vom Anwender gewünschten Rechte zu berücksichtigen.
Auch das wird sicher noch Spaß bringen hier im Forum

Auch die Verzeichnispfade der *drei* Joomla-Hauptanwendungen (Site, Backend, Installer) und dem Framework (/libraries/joomla) waren eigentlich schon in 1.5 flexibel (defines.php) mit der Absicht Fronend und Backend über getrennten Subdomains rennen zu lassen.
Die Idee hat nur keiner mitbekommen :-)
Deshalb findet man in praktisch jeder Extension zuhauf hartkodierte Pfadangaben wie "/administrator/components/com_xx", anstatt die offiziellen (Laufzeit-)Konstanten zu nutzen, als da wären z.B.
- JPATH_SITE / JPATH_ADMINISTRATOR
- JPATH_COMPONENT / JPATH_COMPONENT_SITE / JPATH_COMPONENT_ADMINISTRATOR

Datenmigration
Viel neues und geändertes Datenbankzeug in der 1.6 und sicherlich mal wieder kein direktes und anstandslos funktionierendes Update (der Core-Daten) ohne jeden Pipifatz nachzukontrollorieren und nachzukonfigurieren; ich erwarte die schon heute hassenswerte Quasi-Migration beim neu installieren.
Mit etwas Glück gibt es einen cleveren Update-SQL-Skript der die Tabellenstruktur ad hoc korrigiert und Daten umschaufelt. Mit SQL geht sowas nämlich. (Im SVN liegt bislang noch eine diff_15_to_16.sql)

An dieser geänderten Datenbankstruktur werden all jene 1.5er-Extensions scheitern die irgendwie auf Core-Daten zugreifen (wollen) sich aber nicht der (teilw. auch besch...) Helper-Klassen bedienen und stattdessen eigenen SQL-Code gegen die DB schicken -- hups: SQL-Fehler.

Templates
Bislang (SVN, Dez. '09) sieht es so aus, dass 1.5er-Templates kompatibel sind (auch wenn der Installer derzeit hinkt). Das Prinzip der <jdoc /> Tags ist einigermassen gut durchdacht und theoretisch beliebig erweiterbar, somit spricht alles dafür, diese "Template Engine" für 1.6 beizubehalten. Es könnten ein paar neue Tags und Attribute auftauchen. Wir sind ja zum Glück kurz vor der 1.5-Final nochmal um patTemplate drumrum gekommen.

Nach wie vor finden sich also diese <jdoc:xxx /> Elemente in den aktuellen Templates. Statt einem "Beeze 2.0" in angenehmerer Farbe gibt es zwar ein "Atomic" basierend auf Blueprint -- aber na gut. Nix gegen Blueprint im Speziellen, aber freuen wir uns schon jetzt auf die viele atomaren Klone, die 950px breit, unsere Augen erfreuen.

Frohes Schaffen,
CirTap

*) wer 'nen JoomlaCode-Account hat: contenttypes im SVN

Empfinde die meisten Infos schon als aufbauend.
Auch wenn 2011 wohl wirklich realistisch scheint.

Joomla entwickelt sich - sehr positiv.
Nichts ist stetiger als der Wandel.

Stillstand ist der Tod.

Gruß, reservoir Dog

Ria,
verzeih, wenn dich meine nüchterne Interpretation der Lage ein bisserl desillusioniert , das lag nicht in meiner Absicht, aber ein "alles kein Problem" wäre schlicht gelogen. Ich hab lediglich meine Erfahrungen mit Web-Apps im Allgemeinen, Joomla! im Besonderen und den Leuten dahinter "extrapoliert"
Mit 1.6 wird das fortgesetzt was in der 1.5 begonnen (oder versäumt) wurde und man hat auch den Mut (noch) mehr Relikte zu brechen. Die Änderungen sind aber bei weitem nicht so massiv oder fremdartig wie anno tobac beim Sprung von 1.0 zu 1.5, zumindest technisch.

Vielleicht wäre ich sogar besser damit bedient, als eine entsprechend mit kleinen "Erweiterungen" aufgemotzte 1.5xx, mit der ich dann ganz alleine dastehe.

Ganz bestimmt sogar -- meiner Ansicht nach. Ich für meinen Teil ziehe eine Extension von bspw. JoomlaWorks der von Lieschen Müller oder Fred Daumeier intuitiv vor.
OpenSource ist ja schön und gut und auch dass jeder Extensions schreiben darf(technisch wie rechtlich), heisst aber nicht, dass man es auch jedem erlauben sollte :-)
...denn sie wissen nicht was sie tun!
Es gibt natürlich durchaus Perlen unter den No-Namern, aber wie das mit Perlen nunmal so ist...
Und bevor ich 20 verschiedene Module||Plugins installiere und teste und Zeit damit vergeude festzustellen, dass die dann sowieso nur ansatzweise "das Problem" lösen und andererseits für mich irrelevanten Schnickschnack treiben, hab ich mitunter dank Elkukus EasyCreator, oder aus der hohlen Hand raus, das Mistding selber gecoded.

Die "Big Player" zeigen zumindest moralische Verantwortung für ihre Produkte, egal für welchen Preis diese zu haben sind. Diese Art des Verantwortung-zeigen ist in der OpenSource-Welt leider kein inhärenter Bestandteil ihrer Kultur: provided as-is; Nimm es oder lass es; Mir doch schnuppe ob mein beknackter Code (auch) bei dir läuft oder nicht: hast doch den Quelltext und kannst ihn ändern. DAU!
Ich gehöre zu den Leuten die das auch in der Tat können und schaue immer in den Quelltext rein, weil ich es a) technisch kann b) rechtlich darf und c) mir einbilde, Aufbau und Qualität beurteilen zu können. Natürlich hat jeder eigene Maßstäbe
OpenSource ist toll!

Noch ein Nachschlag zu den Templates
Nachdem ich mein gestriges Pamphlet abgesondert hatte, viel mir später noch ein, dass es evtl. doch nicht SOO arbeitsfrei zugehen wird, möchte man 1.5er Templates in 1.6 nutzen, besonderes wenn man keine oder zuwenige Overrides verwendet.
Ich bin mir zwar sicher, dass es technisch keine echten Probleme geben wird, aber optisch dürfte einiges zusammenfallen: Der Core produziert nun sehr "CSS-lastigen" Output und praktisch alle Klassen und IDs haben sich geändert. Tabellen sind nur dort wo Tabellen auch semantisch Sinn machen.

An einigen Stellen evtl. zuviel DIVitis und ULs bis zum Abwinken, auch dort wo eine DL evtl. sinniger wäre. Alles in allem aber gut und granular stylebar.
In Sachen "template.css" definitiv inkompatibel zu 1.0 oder 1.5 -- was ich persönlich eher begrüsse, weil man letzlich mit weniger CSS mehr "Format" erlangen kann und sowieso eigene Templates backe.
Ein Fest für alle Template-Clubs: das riecht doch streng nach Updategeschäften, Leute!

Dinge wie "contentheader" sind weg: echte <H2> durch die Bank für den Seitentitel der Komponente. Die H2's haben zwar keine class, was aber kein Versäumnis ist, denn jede View hat einen eindeutig benannten DIV-Wrapper mit Klassennamen à la "jcategory-list" oder "jcontent-blog" usw.
Das erwähnte "Atomic" schreibt idiotischerweise wieder diesen nutzlosen XML-Prolog raus, als hätte der nicht schon für genug Ärger im IE gesorgt.

Wer sich das "Core Template" der aktuellen SVN-Version mal im Quältext anschauen will, findet im Anhang ein als Override organisiertes Extrakt aller relevanten PHP-Dateien die ansonsten querbeet unter /components/**/html/ verstreut rumliegen.
Nicht zum installieren geeignet! Keine CSS, keine JS, sondern nur der blanke Code, Stand heute.
PHP-Dateien aufmachen, reingucken, wundern, freuen, fluchen und eventuell lernen was da zukünftig an HTML vom Core ausgespuckt wird.

Ach ja: provided as-is ;-)

Viel Spaß,
CirTap