WebsiteBaker Support (2.8.x) > Diskussion über WB (closed)
Zusätzliche Felder unter Seitenoptionen
escpro:
Hi zusammen
hab den thread jetzt nicht gross gelesen aber die erweiterung würde mir auch gefallen.
Evtl wurde es schon angesprochen aber nun da ja das Jquery einzug erhält wären auch hier einiges an features rauszuholen (alt) etc.
zusätzlich würde sich an alle hardwysewigseitenkl opfer (die ohne module arbeiten) wesentlich mehr freiraum in der "latest news"-ebene ergeben. Jquery wie gesagt wäre es ein leichtes (ohne auf den keyword oder metas zu verzichten) oder googleapi oder oder .... . find ich gut.
Zur WelchesMenu-Anzeige.... hmm hab ich zwar schon im ACC aber ok warum nicht.
cu escpro
--- Quote from: Stefek on June 05, 2009, 01:44:15 PM ---Hallo.
Na, das stößt schn mal auf Interesse.
Ich habe einen "Screenshot" ausgearbeitet, um die Idee auch den anderen, die sich auf all das hier wenig Reim machen können, zu visualisieren.
Das mit Access-Key habe ich nicht mit reingetan - nicht, dass es nicht interessant ist: ich muss einfach zugeben, dass ich davon nicht viel weiß, WebBird :-) Aber ein willkommenes Feature, wie ich bereits bei Deiner EasyMenu Entwicklung mitverfolgen konnte.
Visualisierung:
Die grün hervorgehobenen Felder sind bereits über =>backend=>Optionen zuschaltbar.
Die rot hervorgehobenen sind die, über die wir sprechen
Zu den einzelnen Punkten:
1) ist klar - bereits vorhanden. Man kann es einfach zuschalten über =>backend=>Optionen
2) Frank, Dietmar - der Zusatz für die Seitensprachen
3) Die besagten Custom Fields, frei benennbar wäre sicher gut. Man könnte als Admin auswählen, wo man es ins Template tut; in den Head oder in den Body
4) Alt-Title soll heißen, ein Alternativer Titel. Den könnte man sicherlich ins ShowMenu2 implantieren (aber auch anderweitig im Template ausgeben lassen, z.B.für Headings (H1, H2...) . Damit kann man einige gute Vorteile schaffen, wie z.B. ein XHTML Menü mit folgendem Muster:
<li><a href="[ url ]" title="[alt]">[menu_title]<a></li> (Bringt halt Vorteile bei der Seitenoptimierung. Der Rote Teil ist gutes Futter für Google. Wird bei vielen modernen CMS berücksichtigt.)
5) Abweichende URL - manchmal will man aus bestimmten Gründen eine abweichende URL haben.
6)Kanonische URL - mit der Zeit gehen wirkt auch mal sexy ;-)
Die kleinen Kästchen bei einigen der Felder sind Character-Counter - die werden über JS gezählt, keine Datenbankabfrage nötig - Bernd JM hat dies bereits ausgearbeitet. Das ist wertvoll für Leute, die auf SEO großen Wert legen, wo es manchmal auf die Genauigkeit der Anzahl der "Zeichen" ankommt.
Bitte keine Argumente wie: das ist doch viel zu viel für "Otto". Ja, ist es. Deswegen _zuschaltbar. Wer sich das zuschaltet, weiß, was er tut. Auch bei Punkt 5.
Dieses Argument hebt sich also von selbst auf.
Viele Grüße.
Christian (Stefek)
EDIT// Bei Pkt 6 ist das mit der Extension zuviel. Denkt Euch eine der beiden Extensions weg (entweder die im Textfeld oder die außerhalb davon).
--- End quote ---
Luisehahne:
Hallo,
beziehe auf das Vorgeschlagene von Stefek. Bis auf die CUST_FIELD sind die Felder wie aufgeführt zu begrüssen.
Damit WB Mehrsprachenfähig zu machen sollte für uns kein Problem sein. Ich habe mir auf GRund meiner bisherigen Erfahrungen schon mal Gedanken gemacht, was natürlich zur Diskussion freisteht.
Vorschlag:
Seiteneinstellung Backend, Ordnerstruktur, kann auch verschieden sein
Sprache Page Schlagwort (Sprache egal)
de
Startseite home
Gästebuch guestbook
Impressum imprint
Haftungsausschluss disclaimer
Service Service
Downloads downloads
en
Home home
Service Service
Downloads downloads
Imprint imprint
Disclaimer disclaimer
usw.
Bei Anlegen einer Seite wenn Seitensprache != DEFAULT_LANGUAGE Liste bereits erfasster Schlagwörter (vorzugsweise die der DEFAULT_LANGUAGE) zur Auswahl anbieten und zuordnen.
Wäre auch gut, wenn man sich im Sprachenzweig befindet, sofort automatisch bei hinzufügen einer Seite die Seitensprache des Zweiges in dem die Seite hinzugefügt als Vorgabe setzen zu lassen. Müsste dann auch in menu_link berücksichtig werden. Das Modul menu_link muss ja sowie so überarbeitet werden, da es fehlerhaft ist.
Frontend
Abfrage welche Sprache ist zurzeit aktiv. Diese bei der Suche ausklammern. Schlagwort der nächsten Sprache suchen. Fertig? Dann nächste Sprache usw. Lässt sich ja wunderbar über parent und root_parent und level lösen.
Da root_parent ja die page_id der Startseite der jeweiligen Sprache ist, lässt sich ein nachträgliches Erschaffen eines Mehrsprachenauftrit tes ohne Problem erstellen.
Sollte die Sprachenseite nicht vorhanden sein, sollte der Flaggenlink zur Startseite verweisen. Ob mit einem kleinen Dialogfenster darauf hingewiesen werden soll, ist mit jquery kein Problem, dann natürlich mit einer entsprechenden Sprachenfehlermeldu ng. Alternativ könnte man auch zur Sitemap springen, wenn eine vorhanden ist.
Die SEO Felder kann ich so vorbehaltlos akzeptieren
Die Zusatzfelder, ist ja schon angesprochen worden, würde ich jetzt auch weglassen, es sei denn das Core bräuchte diese irgendwann, aber betimmt nicht für Moduleentwickler. Das gäbe wirklich nur Chaos.
So das sind meine Gedanken dazu. Ich hoffe, das ich mich diesmal etwas verständlicher ausdgedrückt habe.
Gruss
Dietmar
Stefek:
Hallo Dietmar.
--- Quote from: Luisehahne on June 05, 2009, 09:27:32 PM ---Wäre auch gut, wenn man sich im Sprachenzweig befindet, sofort automatisch bei hinzufügen einer Seite die Seitensprache des Zweiges in dem die Seite hinzugefügt als Vorgabe setzen zu lassen. Müsste dann auch in menu_link berücksichtig werden. Das Modul menu_link muss ja sowie so überarbeitet werden, da es fehlerhaft ist.
--- End quote ---
Das habe ich mir auch schon öfter vorgestellt.
--- Quote from: Luisehahne on June 05, 2009, 09:27:32 PM ---Abfrage welche Sprache ist zurzeit aktiv. Diese bei der Suche ausklammern. Schlagwort der nächsten Sprache suchen. Fertig? Dann nächste Sprache usw. Lässt sich ja wunderbar über parent und root_parent und level lösen.
--- End quote ---
Auch das (obwohl zum Thread etwas ot) ist eine sehr vernünftige Idee.
--- Quote from: Luisehahne on June 05, 2009, 09:27:32 PM ---Die SEO Felder kann ich so vorbehaltlos akzeptieren
--- End quote ---
Yepp.
--- Quote from: Luisehahne on June 05, 2009, 09:27:32 PM ---Die Zusatzfelder, ist ja schon angesprochen worden, würde ich jetzt auch weglassen, es sei denn das Core bräuchte diese irgendwann, aber betimmt nicht für Moduleentwickler. Das gäbe wirklich nur Chaos.
--- End quote ---
Diese Felder sind weniger für Modulentwickler gedacht. Sie würden nicht stören, solange sie _zuschaltbar_ wären.
Ich denke, ich bin nicht der einzige, der Verwendung für findet.
Ich kann mir zwar vorstellen, dass diese CustomFelder vor allem gut sind für fortgeschrittene Anwender, oder wenn der, der die Seite erstellt sie auch später pflegt, aber ich würde sie nicht mehr missen wollen, wenn sie einmal drin wären.
Vielen Dank für Deine Ideen.
Gruß,
Stefek
BlackTiger:
Hallo,
um die Mehrsprachigkeit elegant in den Griff zu kriegen ist ein zusätzliches Feld sicherlich mehr als hilfreich. Es wäre dann aber auch gut noch einen Schritt weiterzugehen und von vornherein den Aufbau mehrsprachiger Sites besser zu unterstützen. Bisher muss man ja einen entsprechenden Seitenbaum mit den einzelnen "Sprachwurzeln" selbst pflegen. Praktischer wäre eine sprachorientierte Ansicht (z.B. über Tabs), in der man nur den Seitenbaum der jeweiligen Sprache verwaltet.
Die Felder zur Suchmaschinenoptimi erung klingen ebenfalls sinnvoll - wenn ich auch den Sinn des Feldes für die kanonische URL nicht ganz verstehe - gibt es bei euren WB-Installationen unterschiedliche Seiten mit identischem Inhalt?
Benutzerdefinierte Felder sind sicherlich auch eine tolle Sache, da werden dann aber sicherlich schneller neue verlangt als sie erstellt werden können. ;) Daher finde ich eine Lösung mit den Variablenzuordnunge n praktischer. Oder man packt alle Custom-Felder in ein einziges Tabellenfeld muss das aber dann jeweils zusammen- bzw. auseinanderpfriemel n.
Die Core-Tabellen auf eigene Faust zu erweitern ist keine so gute Idee, da das mit der Einführung der Unterstützung des Strict-Modus (die für spätere Releases geplant ist) wohl zu Problemen führen wird.
Gruß
Michael
susigross:
@Stefek:
Ja der Punkt 2 steht genau goldrichtig, da hab ich nichts zu bemängeln.
@LuiseHahne:
Mir ist nicht so richtig klar, zu was der ganze Aufwand in deinem letzten Beitrag zur Mehrsprachigkeit gut sein soll.
Ist aber auch nicht so schlimm, ich muss ja nicht alles verstehen 8-)
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version