WebsiteBaker Community Forum
WebsiteBaker Support (2.8.x) => 
Hilfe & Support (deutsch) => General Help & Support => Diskussion über WB (closed) => Topic started by: Stefek on June 04, 2009, 11:31:09 PM
-
Hallo,
ich habe einige Überlegungen, die aufgrund meiner Erfahrung im Umgang mit WB Vorteile mit sich brächten.
Es hat alles mit den Seiten-Einstellungen zu tun.
Ich stelle es hier erstmal so rein und würde mich über eine Diskussion freuen.
Folgende Felder in den Seitenoptionen wären vorteilhaft:
- Zusätzliches Feld für Title ("Title2", "Alt-Title" oder so ähnlich) Zweck: Die H1 könnte bedenkenlos über das Template ausgegeben werden, wäre nicht identisch mit dem PageTitle. Man könnte es auch im SM2 verwenden, um den Links ein alt-Attribut hinzuzufügen.
- Kanonische URL(Um die derzeitigen SEO Trends mitzuliefern)
- URL per Hand Eingabefeld - sodass die URL anders als der Menu-Title ist (um sie mit zusätzlichen Keywords zu füttern, oder aussagekräftiger zu machen, uswr...)
- Noch ein kleines (oder über Optionen frei definierbare Menge) Zusatzfeld (Textarea) wäre gut; wäre Sinnvoll für verschiedene Zwecke (z.B. ein Zusatz im Footer auf bestimmten Seiten, ein Eintrag im Head für bestimmte Seiten etc.)
All diese Felder müßten über Seitenoptionen->Erweiterte Seitenoptionen frei zuschaltbar sein - so wie jetzt die Seitensprachen, mehrere Menüs usw. (Sie bei der Standardinstallatio n von Vornherein auf aktiv zu setzen, würde zu "Abschreckend" wirken).
MfG,
Christian (Stefek)
-
Ich bin noch für ein Feld "PageCode" oder auch "Schlagwort", welches man sehr sinnvoll für die Sprachumschaltung gebrauchen kann. Der Code dafür ist ja schon fertig, siehe z.B. hier (http://wbdemo.heysoft.de/pages/de/easymultilang.php).
Ich bin dagegen, so was zusammen mit anderen Infos vom Benutzer in ein allgemeines Zusatzfeld einzugeben.
Gründe:
- es ist kompliziert für den Benutzer, mehrere Infos so in ein Feld zu schreiben, daß das Programm sie dann richtig zuordnen kann
- es ist umständlicher und fehleranfälliger für das Programm, Benutzereingaben aus einem Feld zu parsen und sich das zutreffende Stück herauszusuchen, als direkt aus einem dedizierten Feld auszulesen
Für die Einfachheit der Bedienung wäre es natürlich von Vorteil, wenn der PageCode direkt unter der Sprache eingegeben werden kann. Den MS-Windows-Weg mit viel zu vielen Fensterchen finde ich nicht so ergonomisch.
-
Ja, auch mich dürstet nach ein paar Feldern mehr.
Bei einer meiner Installationen habe ich ein Feld "pagename" (=wie URL, aber kürzer) , das automatisch erzeugt wird, aber verändert werden kann. Ich verwende es, um u.a. bei den Suchergebnissen zu jeder Seite ein Bildchen zu zeigen.
Klar, das sind spezielle Sachen, aber ein paar Extra felder tun nicht weh.
-
Hallo,
@Stefek
Werde mir das in Ruhe mal durch den Kopf gehen lassen. Die Idee ist gut.
@FrankH
obwohl ich persönlich ja auch zu diesem Vorschlag tendiere. Wäre dann auch eine wunderschöne TagCluds Geschichte. Immer nur ein gemeinsames Schlagwort für alle Sprachen. Meine derzeitiges Modul schafft das bereits schon mit dem gleichen Schlagwort die Sprache zu finden.
Ich hatte mir so vorgestellt ein Feld für das Schlagwort und 1 Feld, ich nenne es mal language_trail für die vorhanden Sprachen anzulegen.
Ich lasse mir mal alles durch den Kopf gehen. Auf jeden Fall ist Multilanguagefähigk eit, egal wie, ein Plus für WB. Hauptsache wir bekommen vom Team die zusätzlichen FElder. Vielleicht wäre es für künftige WB-Versionen, wenns die Leistung nicht in die Knie zwingt, Bei jeder Tabelle Dummyfelder mit anzulegen. Könnte mir vorstellen, dass dies für manchen Modulentwickler von Vorteil wäre und machen zusätzliche anzulegende Tabelle und damit Zeit bei der Abfrage, einsparen könnte.
Gruss
Dietmar
-
@Luisehahne:
Ich hatte mir so vorgestellt ein Feld für das Schlagwort und 1 Feld, ich nenne es mal language_trail für die vorhanden Sprachen anzulegen.
Wozu 2 Felder? Schau dir doch einfach mal meine Lösung an, da reichen ein Feld und ein Schlagwort, egal wie viele Sprachen es gibt.
Der User hat hier viel weniger Tipparbeit als in deiner Lösung :-D
Bei jeder Tabelle Dummyfelder mit anzulegen
Die Idee mit den Dummy-Feldern hat einen Haken: Wer zuerst kommt, belegt sie, die anderen schauen in die Röhre...
-
Finde ich gut. :-)
Ansonsten wäre es noch schön, wenn man alle Attribute belegen könnte, die per W3C-Standard für Links vorgesehen sind. Manche sind vielleicht weniger wichtig (etwa die verwendete Sprache des Verweisziels, wird eher wenig genutzt), andere schon eher (wie "accesskey").
Ich habe das bei EasyMenu eingebaut; die Liste der erlaubten Attribute sowie deren Inhalte (sofern fest vorgegeben, etwa bei "shape" oder "type") ist extern definiert, so daß Anpassungen (falls sich der Standard ändert) ein Kinderspiel sind. Das Formular wird dann automatisch anhand der externen Definition generiert. (Das mache ich bei Optionen sehr gerne so, weil man nur einmal den Generator schreiben und bei neuen Feldern später nur die Definition ergänzen muß, schon paßt sich alles andere automatisch an.)
Man kann übrigens so auch auf sehr einfache Weise beliebig viele, auch benutzerdefinierte, Felder vorsehen. Man speichert die Optionen nicht "flach" in der Datenbank, also ein Set Optionen = eine Zeile in der Tabelle, sondern "vertikal".
Beispiel:
Spalten - id, attribute, value
"id" ist einfach eine fortlaufende Nummer und kann sicherlich auch weggelassen werden, ich habe aber immer gern ein autoincrement-Feld.
"attribute" ist der Name des Attributs. (Klar.)
"value" ist der Wert des Attributs. (Auch klar.)
Wenn man sich nun später überlegt, daß man ein neues Attribut braucht, geht man folgendermaßen vor:
* Definition in Definitionsdatei eintragen (Name des Attributs, Typ des Wertes (z. B. Text oder Zahl), mögliche Wertevorgaben zur Erzeugung eines Dropdown)
* Verwendung des Attributes an passender Stelle umsetzen.
Fertig! Ernsthaft, das ist alles! Der Formulargenerator erzeugt anhand der Definition das Eingabefeld, die Funktion für die Pflege der Attribute in der Datenbank nimmt einfach die Eingabedaten und schreibt sie in die DB, man muß sonst nichts ändern. Nur die Verwendung des neuen Attributes läßt sich halt nicht automatisieren.
Wäre vielleicht langfristig ein Ansatz für den WB-Core. (Das Vorgehen habe ich selbst ja auch für Admin-Backends erarbeitet, ursprünglich in Perl, daher ist meine Umsetzung in PHP noch nicht 100% ausgegoren, ich müßte mich halt mal hinsetzen und das mit PEAR-Klassen unterfüttern.)
-
"...die Funktion für die Pflege der Attribute in der Datenbank nimmt einfach die Eingabedaten und schreibt sie in die DB..."
Das wollte ich sicherheitshalber noch sagen: In EasyMenu ist ein erster Entwurf eines Formulardaten-Validators enthalten, der auf PEAR::Validate basiert. Man gibt vor, welche Attribute man erwartet und welchen Inhaltstyp diese haben dürfen. Man kann auch eine vorgegebene Werteliste (für Dropdownfelder) vorgeben, so daß nur Werte aus dieser Liste erlaubt sind. Wen's interessiert, kann ja mal in die Validator-Klasse in EM und die init.php gucken.
Die Werte werden also nicht "blind" in die DB geschrieben. :wink:
-
Hallo,
@FrankH
Jau mit den zusätzlichen Feldern haste recht. First come, First serve. Danke, Vorschlag gestrichen. Das 2 Feld für den Umschalter ist einfach für die Sprachenfestlegung gedacht, als Trail, z.B. DE,EN,FR,NL usw. ich arbeite in meiner Version insoweit damit, das ich die anderssprachigen Seiten in der Seiteneinstellung die Sprache zuordne, über GROUP BY feststelle wieviele Sprachen vorhanden sind, ein Trailarray erstelle und so in einer Schleife das Gegenstück suche. Meine nur aus Geschwindigkeitsgrü nden, das fest zu hinterlegen wäre besser. Gut könnte auch wegfallen. Ich muss mir mal deine Lösung anschauen. Was ist bei dir mit der Seitenstruktur? Bei mir kann sie wild durcheinander sein. Ich brauche halt nur das zusätzliche Schlagwortfeld, da ich im Moment den PAGE_TITLE dazu missbrauche und das sieht eben nicht hübsch aus. Fazit: Man nehme 3 Lösungen, einigit sich, nimmt das beste aus jeder und das Ergebnis ist 100%ig.
-
Ich muss mir mal deine Lösung anschauen. Was ist bei dir mit der Seitenstruktur? Bei mir kann sie wild durcheinander sein.
Seitenstruktur ist bei mir auch egal. Ich muss dazu auch nichts misbrauchen.
So das wird hier OT, ich äußere mich in diesem Thread nicht mehr weiter dazu.
-
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
(https://forum.WebsiteBaker.org/index.php?action=dlattach;topic=14057.0;attach=4384;image)
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 (http://pixelfolk.net/seo/119/kanonische-urls)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).
[gelöscht durch Administrator]
-
und immer davon ausgehend, dass die Felder auch reinkommen.
@FrankH
Ich ändere ungern was am Core. Was ist nach einem Update? Die Struktur von WB 2.8 ist ja schon anders und ich kann dein easymenu, welches hervorragend ist, nicht einsetzen.Per install.php ein Feld zur Tabelle hinzuzufügen ist kein Problem, das stört auch das Core auch nach einem Update nicht. Nur die Überlegung muss sein, wie löse ich die ZUordnung, immer vorausgesetzt, dass die zusätzlichen FElder nicht genehmigt werden. Ich hatte so die Idee, wenn man als Administrator eingeloggt ist, dies mit einem Dialgfenster über das FRontend zu verwirklichen.
@Stefek
Danke für deine Arbeit, um das Ganze mal auf einen Nenner zu bringen. So stelle ich mir ZUsammenarbeit vor
Gruss
Dietmar
-
Ich ändere ungern was am Core. Was ist nach einem Update?
Luise, das genau ist doch der Grund, warum es diesen Thread gibt.
Wenn der Core zentral geändert wird, (und das ist unser aller Ziel,) brauchen wir es nicht selbst zu tun und haben Gewissheit, dass alles stabil bleibt.
-
Ich ändere ungern was am Core. Was ist nach einem Update?
Luise, das genau ist doch der Grund, warum es diesen Thread gibt.
Wenn der Core zentral geändert wird, (und das ist unser aller Ziel,) brauchen wir es nicht selbst zu tun und haben Gewissheit, dass alles stabil bleibt.
also ich bin ja kein programmierer - aber meiner ansicht nach wenn es um änderungen im Backend oder Sprachfunktionalitä t geht - sollte das in den core rein - weil das ja bestandteile des core's sind....?
gebt mir eine kopfnuss wenn ich falsch lieg... :oops:
coreänderungen bei modulen/snippets ....weniger benutzerfreundlich
coreänderungen für backend/neue features ....schätz ich kaum vermeidbar
grüße aus dem freistaat
martin
-
Hallo,
@Mr-Fan
Die Änderungen die meinte, bezogen sich auf die Datenbank, und das ist dem Core egal. Lieber wäre mir auch die andere Lösung.
Gruss
Dietmar
-
Die Änderungen die meinte, bezogen sich auf die Datenbank, und das ist dem Core egal.
Nee das sehe ich anders.
Einträge in der pages-Tabelle werden im Backend gemacht, größtenteils in den Seiteneinstellungen .
Da diese Seiteneinstellungen für alle Module gleich sind, gehören sie zum Core.
Das Formular und die Tabelle gehören zusammen, also beide zum Core.
-
@FrankH
Ich ändere ungern was am Core. Was ist nach einem Update? Die Struktur von WB 2.8 ist ja schon anders und ich kann dein easymenu, welches hervorragend ist, nicht einsetzen.Per install.php ein Feld zur Tabelle hinzuzufügen ist kein Problem, das stört auch das Core auch nach einem Update nicht. Nur die Überlegung muss sein, wie löse ich die ZUordnung, immer vorausgesetzt, dass die zusätzlichen FElder nicht genehmigt werden.
Das ging wohl an mich, auch wenn da FrankH steht. ;)
Warum sollte ich EM mit 2.8 nicht mehr verwenden können?
-
Einträge in der pages-Tabelle werden im Backend gemacht, größtenteils in den Seiteneinstellungen .
Da diese Seiteneinstellungen für alle Module gleich sind, gehören sie zum Core.
Das Formular und die Tabelle gehören zusammen, also beide zum Core.
Das ist korrekt, hindert aber ein Modul nicht daran, zusätzliche Seiteneinstellungen selbst zu verwalten.
Ich hatte diesen Thread allerdings so verstanden, daß es darum geht, den Core zu verändern. Insofern ist die Diskussion über die Updatefähigkeit eigentlich hinfällig. Nach meinem Verständnis geht es nicht darum, unabhängig von der Core-Entwicklung an selbigem rumzufummeln, sondern im Zuge der Weiterentwicklung diese Änderungen herbei zu führen.
-
ich bin dafür, dass Matthias sich hierzu auch mal äussert, damit wir das zu Ende bringen was wir angefangen haben.
Gruss
Dietmar
-
Hallo Webbird,
deine Frage möchte ich noch gerne beantworten
Warum sollte ich EM mit 2.8 nicht mehr verwenden können?
Weil sich bereits das Core dort geändert hat. Code und Templates sind im Admin bereich komplett getrennt. Deswegen ist das settings.html im Ordner pages inzwischen fehl am Platze.
Gruss
Dietmar
-
EM macht aber gar nix damit. Das ist alles völlig autark.
Edit: Ich glaub, wir reden nicht vom gleichen Thema. *g*
Edit: Also nur damit hier keine Gerüchte entstehen... ich habe gerade EasyMenu 0.31 mit Trunk 985 von WB 2.8 getestet, und es funktioniert einwandfrei. Einschließlich der Seitenoptionen wie "accesskey".
-
Oh s***, stimmt, es war das multilanguage von FrankH. Jetzt gehe ich in Pension.
Gruss
Dietmar
-
Oh s***, stimmt, es war das multilanguage von FrankH. Jetzt gehe ich in Pension.
Gruss
Dietmar
nein bitte nicht..... :lol: wär schade - easymenu is ja wieder ganz was anderes und funtzt einwandfrei (accesskey's sind eine lustige sache) ... eher wird das easymenu das Showmenu2 für standarddinge ablösen und auch vielleicht für mehr (auch wenn das webbird noch nicht so sieht - dein baby wächst und wächst :wink:)
multilanguage ist von frank und auch die languagematrix von iceat und noch ein snippet von doc...... :?
ALSO bitt auch wenn's hier OT ist - alle entwickler sollten sich das AMASP - UPCOMING ITEMS zuherzen nehmen!
@frankH dein Vorgehen beim MPFORM echt klasse vorher grobes konzept -> ankündigung forum/amasp -> ideesammlung ->durchführung....
@alle coder kräfte sparen und an gemeinsamen projekten arbeiten oder sich in gruppen zusammenschließen wie zum beispiel für projekte wie dieses hier!
KWeitzelhat mir auch mitgeteilt das auf dem .project server noch recourcen frei wären für einige svn's oder dergleichen!?! das würde sich auch anbieten für eine ausarbeitung z.B. der Jquery implatierung in WB wobei die english und vorallem niederländischen kollegen nicht ausgeschlossen sein sollten!
so viel dazu....
mehr dazu gibts hier!
https://forum.WebsiteBaker.org/index.php/topic,13624.0.html (https://forum.WebsiteBaker.org/index.php/topic,13624.0.html)
grüße martin
-
Macht nix, kann passieren, wenigstens hab ich jetzt EM schon mal mit 2.8 getestet und noch schnell eine Version 0.32 mit zwei, drei kleinen Korrekturen rausgegeben. :-D Hat doch was gebracht. :wink:
So, jetzt klink ich mich aber aus, ich hab URLAUB! *freu* Vielleicht misch ich mich nächste Tage nochmal ein, wenn ich Langeweile hab, aber ab Mittwoch hab ich kein Inet mehr, dann habt Ihr Ruhe. :wink:
-
War ja meine Alters Demenz noch von Nutzen. Man kommt ja auch ganz durcheinander, wenn man in so vielen Threads rumturnt. Sorry for all the trouble. Versuche demnächst das besser auseinander zu halten.
Gruss
Dietmar
-
Ich hatte diesen Thread allerdings so verstanden, daß es darum geht, den Core zu verändern. Insofern ist die Diskussion über die Updatefähigkeit eigentlich hinfällig. Nach meinem Verständnis geht es nicht darum, unabhängig von der Core-Entwicklung an selbigem rumzufummeln, sondern im Zuge der Weiterentwicklung diese Änderungen herbei zu führen.
Korrekt, Bianka.
Die Idee war, eine Diskussion anzuregen, ob diese Änderungen im Core Sinn machen würden.
Viel Interesse, wie ich sehe.
@Stefek
Danke für deine Arbeit, um das Ganze mal auf einen Nenner zu bringen. So stelle ich mir Zusammenarbeit vor..
Ich habe mich schon öfter dazu geäußert und wollte es jetzt mal als "Komplettpaket" erneut anregen.
Ja, auch mich dürstet nach ein paar Feldern mehr.
Bei einer meiner Installationen habe ich ein Feld "pagename" (=wie URL, aber kürzer) , das automatisch erzeugt wird, aber verändert werden kann. Ich verwende es, um u.a. bei den Suchergebnissen zu jeder Seite ein Bildchen zu zeigen.
Klar, das sind spezielle Sachen, aber ein paar Extra felder tun nicht weh.
Ich würde mich freuen, wenn Chio nochmal was dazu sagen würde - aus SEO Sicht, aber auch bezogen auf den im Zitat erwähnten "Hack": würde eine Seiteneinstellungen Maske, wie im "Screenshot" sichtbar, bei Deinem Workaround helfen, bzw. die Problematik gradliniger Lösen?
Für die Einfachheit der Bedienung wäre es natürlich von Vorteil, wenn der PageCode direkt unter der Sprache eingegeben werden kann.
Frank, mein Punkt 2) im "Screenshot" ist etwas dürftig. Könntest Du ein Beispiel hochschicken, wie Du es lösen würdest?
Schickt doch alle mal was hoch. Wir können es gerne ausarbeiten gemeinsam (ich kann es nicht programmieren, aber ausklamüsern, da kann ich behilflich sein).
Wenn wir die Idee weiterspinnen und uns einig sind, wird auch Matthias leichter ein Urteil fällen können.
Aus gemeinsamen Gesprächen mit ihm weiß ich, dass er in dieser Hinsicht mit mir einer Meinung ist: wenn es WB weiterbringt, ist es gut.
Und schließlich sind wir es, die damit arbeiten. Es ist ein Werkzeug.
Und selbst wenn keine Zeit da ist, um alles in das 2.8 zu packen... Upgrades sind doch dazu da, um das Werkzeug zu verbessern. ;-)
Viele Grüße,
Stefek
-
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
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
(https://forum.WebsiteBaker.org/index.php?action=dlattach;topic=14057.0;attach=4384;image)
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 (http://pixelfolk.net/seo/119/kanonische-urls)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).
-
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
-
Hallo Dietmar.
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.
Das habe ich mir auch schon öfter vorgestellt.
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.
Auch das (obwohl zum Thread etwas ot) ist eine sehr vernünftige Idee.
Die SEO Felder kann ich so vorbehaltlos akzeptieren
Yepp.
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.
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
-
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
-
@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-)
-
Hallo,
@FrankH
Sicher gingen meine Ausführungen etwas über das Thema hinaus. Es geht mir aber auch darum, dass die Mehrsprachfähigkeit umgesetzt wird. Es gibt ja schon bereits Lösungen. Ich bin gegen eine feste Struktur. Der Anwender sollte auch in der Lage sein, nachträglich seine Seite mehrsprachfähig zu machen, ohne stundenlang die Struktur zu ordnen. Dies geht 100%ig mit meiner Logik. Ich habe es ausgetestet, indem ich Menupunkte wild durcheinander gewürfelt habe. Nur habe ich halt für meine provisorische Lösung die Schlagwörter im Seitentitel setzen zu müssen, weil ich kein Feld dafür zur Verfügung hatte. Wird sich wohl jetzt hoffentlcih erledigen.
Gruss
Dietmar
-
n'Morgen (grunz, muffel..)
Im großen und Ganzen bin ich mit den vorgeschlagenen Feldern einverstanden.
"Canonical Url" halte ich für überflüssig, mit WB hat man dieses Problem ohnehin nicht, und dort wo man es hat, hilft die Canonical URL auch nicht.
Der Link Titel? Der kann auch einfach der Titel sein.
Man muss ja auseinanderhalten:
Einige Felder brauche ich im Menü, da muss also das Menü-Modul angepasst werden.
Andere brauche ich in der Suche.
Andere im Template.
Was letztes betrifft: Man könnte einfach SPH + registerfrontend-kram in EIN Teil zusammenbacken und dabei auch gleich alle Felder in der PagesTabelle mit ihrem Feldnamen als (zb) Kontante zur verfügung stellen. Dann kann sich jeder basteln, was er will.
Was für mich übrigens auch noch wünschenswert wäre: Das Target nur bei Bedarf und zuschaltbar. Standard: keines.
-
Im großen und Ganzen bin ich mit den vorgeschlagenen Feldern einverstanden.
Hört sich gut an.
"Canonical Url" halte ich für überflüssig, mit WB hat man dieses Problem ohnehin nicht, und dort wo man es hat, hilft die Canonical URL auch nicht.
Im prinzip hast Du ja Recht.
Und ich meine, wenn man zusätzliche Felder (in der Beispielgraphik CUST_FIELD unter Punkt 3)) hätte, könnte man die auch in den HEAD schreiben und so auch zu der Kanonischen URL kommen.
Der Link Titel? Der kann auch einfach der Titel sein.
Kann sein, dass ich Dich hier nicht verstehe. Oder dass wir uns beide nicht verstehen.
Jedenfalls, wie ich es mir gedacht habe, ist (in der oberen Graphik bei Punkt 4)) die Alt-Title Eingabe (die kann man auch anders nennen, das ist nur ein Vorschlag. Sub-Title wäre wahrscheinlich weniger verwirrend).
Was will ich damit? Und welche Vorteile würden sich für alle Nutzer ergeben?
(Vorausgesetzt brofield würde dies ins SM2 implementieren) könnte man es über Show_Menu2 aufrufe in Menüs schreiben. Zwar kann man dafür auch den Title nehmen, aber das will ich nicht, weil der meistens an die 40-50 Zeichen lang ist und als Tool-Tip scheiBe aussieht.
Außerdem könnte man neue Menüs sich einfallen lassen, wie z.B. diese hier
(http://media1.smashingmagazine.com/images/navi-menus/okb.png)
(http://media1.smashingmagazine.com/images/navi-menus/free.png)
(http://media1.smashingmagazine.com/images/navi-menus/lon2.png)
Dieses benannte Feld würde es ermöglichen - ohne Hacks.
User Argos, der auch gut als Webdesigner unterwegs ist, hat da schon einmal nach gefragt:
https://forum.WebsiteBaker.org/index.php/topic,13139.msg80054.html#msg80054
//EDIT... und man könnte dies, wenn man smart ist, im showmenu2 dann auch so verwenden, dass man einzelne menü-links mit zusätzlichen Klassen versieht - so nebenbei erwähnt.
Was für mich übrigens auch noch wünschenswert wäre: Das Target nur bei Bedarf und zuschaltbar. Standard: keines.
Da gebe ich Dir Recht. Sollte weg als "default".
Was letztes betrifft: Man könnte einfach SPH + registerfrontend-kram in EIN Teil zusammenbacken und dabei auch gleich alle Felder in der PagesTabelle mit ihrem Feldnamen als (zb) Kontante zur verfügung stellen. Dann kann sich jeder basteln, was er will.
SPH im Core wäre sicher eine gute Sache.
Doch was, wenn neue Module hinzukommen? Und die möchten auch von SPH profitieren bzw. sich dort einnisten?
Vielen Dank an alle, die soweit an diesem Thread beteiligt sind.
Ich hoffe, kommen noch ein paar mehr.
Stefek
-
Was letztes betrifft: Man könnte einfach SPH + registerfrontend-kram in EIN Teil zusammenbacken und dabei auch gleich alle Felder in der PagesTabelle mit ihrem Feldnamen als (zb) Kontante zur verfügung stellen. Dann kann sich jeder basteln, was er will.
SPH im Core wäre sicher eine gute Sache.
Doch was, wenn neue Module hinzukommen? Und die möchten auch von SPH profitieren bzw. sich dort einnisten?
Hallo Chio,
habe gestern nochmal darüber nachgedacht.
Sicher könnte man das SPH im Core haben, so ähnlich wie SM2 mit ausgeliefert wird.
Ebenfalls Dein Multi-Code / Code2 oder wie das Ding heißt wäre eine gesunde Alternative zum Code Modul (oder als sekundäres Code Modul, sodass beide ausgeliefert werden).
Wer benutz noch das Code-Modul, nachdem er einmal das Code2 installiert hat?
Stefek
-
Hallo Zusammen,
ich finde diese Ideen sehr gut, besonders die für die SEO
(alt für die Menu links, den Seiten-Namen selbst vergeben - nicht den Menütitel nutzen, ...... )
Zum Sprachen Problem:
währe es nicht denkbar, die Sprachenumschaltung anhand der Seiten ID zu machen?
Bei den Seiteneinstellungen ein Feld, in dem man die ID der Seite in der anderen Sprache einträgt???
Bei mehreren die ID mit komma trennt? Die Reihenfolge der ID's müsste natürlich festgelegt werden.
Gruß Bastian
-
Hallo Zusammen,
ich finde diese Ideen sehr gut, besonders die für die SEO
(alt für die Menu links, den Seiten-Namen selbst vergeben - nicht den Menütitel nutzen, ...... )
Ich hoffe sehr, dass die Entwickler sich dessen für die 2.9 Version annehmen.
Im Moment sind die ja noch beim Feintuning für 2.8.
Kann sein, dass sie dann aber nach dem Final Release Luft für neue Ideen haben. Diese hier liegt mir am meisten am Herzen.
Gruß,
Stefek
-
Hi Bastian,
währe es nicht denkbar, die Sprachenumschaltung anhand der Seiten ID zu machen?
klar ginge das mit page_ids, nutzt glaube ich so auch das Modul von FrankH.
Wer benutz noch das Code-Modul, nachdem er einmal das Code2 installiert hat?
Ach da gibt es noch einige, zumal dank EditArea nun auch vernünftiges Syntax Highlighting mit dem Code Modul geht. Auch beim page clone modul gabs Probleme mit code2 (keine Ahnung ob gelöst). Da der Zugriff auf das Code Modul nur Admins erlaubt werden sollte, sollten PHP/HTML Ausgaben mit Heredoc auch mit dem Code Modul keine allzu grossen Hürden darstellen.
Wers bequemer mag, kann immer noch Code2 nehmen und gut :wink:
Doc
-
Ich hoffe sehr, dass die Entwickler sich dessen für die 2.9 Version annehmen.
Im Moment sind die ja noch beim Feintuning für 2.8.
Kann sein, dass sie dann aber nach dem Final Release Luft für neue Ideen haben. Diese hier liegt mir am meisten am Herzen.
Gabs denn schon mal nen Future-Request für dei nächste WB Version?
In 2.8 kommt es bestimmt nicht mehr - zu viel aufwand, aber in die 2.9 vielleicht?
Gruß Bastian
-
Hi,
Gabs denn schon mal nen Future-Request für dei nächste WB Version?
Soweit ich weiss nicht. Oft geraten geeignete "Werkzeuge" (wie z.B. Feature Request) bei den vielen Diskussionen hier im Forum in den Hintergrund. Was bleibt sind lange Threads mit teils guten Ideen, die dann aber nach hinten durchgereicht werden und so von der "To-Do-Liste" des Dev-Teams verschwindet :wink:
Feature Requests einfach über die WB Projektseite erstellen:
http://project.websitebaker2.org/newticket
Doc
-
Hallo Bastian,
ja, für 2.8 geht ja nicht, weil es schon in der "Veröffentlichungsph ase" ist, wo ein FeatureFreeze herrscht - jetzt werden nur noch Bugs gebügelt.
Einen Request gab es glaube ich nicht.
Das Thema ist aber bekannt, ich hoffe, dass das Gespräch sich wieder aufrollt, wenn die Coder einmal die 2.8 unter Dach und Fach haben. Einige sind sich der Vorteile der zZusatzfelder sehr bewußt - wie man am Thread erkennt - andere schweigen sich aus :-)
@Doc,
ja interessant, Code jetzt mit SyntaxHilight.
Hast recht, wer mehr will, installiert Code2 nach.
Übrigens, könnte man vielleicht auch in Code2 so ein SyntaxHi reintun... aber ist mir eigentlich wurscht.
Die ganzen Loops in Modulen laufen auch ohne Highlighting gut.
Gruß,
Stefek
-
Oft geraten geeignete "Werkzeuge" (wie z.B. Feature Request) bei den vielen Diskussionen hier im Forum in den Hintergrund. Was bleibt sind lange Threads mit teils guten Ideen, die dann aber nach hinten durchgereicht werden und so von der "To-Do-Liste" des Dev-Teams verschwindet :wink:
Da magst Du wohl recht haben :oops:
Habe das Teil noch nie verwendet. :roll:
Sollte ich mal.
So viele Wünsche habe ich eigentlich nicht :-D
Und Diskussionen finde ich wichtig, weil man die Ideen dann variieren kann, wenn man andere Gesichtspunkte berücksichtigt.
Gruß,
Stefek
-
Hi,
Habe das Teil noch nie verwendet.
Ich weiss, solltest Du aber.
WB 2.7 wurde vor 15 Monaten (http://project.websitebaker2.org/changeset/836) released. Oft vergeht mitunter ein halbes Jahr, bevor wieder an einer neuen Version gearbeitet wird. Versuch mal in einem halben Jahr die guten Vorschläge aus der Masse der Poste im Forum zu finden, schlichtweg unmöglich.
Ein Feature Request (oder Bug report) generiert ein Ticket im TRAC System, welches vom Dev-Team reviewed und akzeptiert oder mit Begründung verworfen wird. Kleiner Diskussionen (streng am Thema) können ebenfalls mit TRAC realisiert werden. Oft sieht man auch, in welcher zukünftigen Version dieses Feature Einzug erhalten wird. Auf jeden Fall hilft ein solches System, auch noch nach einem Jahr die brauchbaren Threads im Forum zu finden (vorausgesetzt sie wurden in TRAC verlinkt) um die gewünschten Änderungen in zukünftige Versionen einfliessen zu lassen.
Doc
-
Übrigens, könnte man vielleicht auch in Code2 so ein SyntaxHi reintun... aber ist mir eigentlich wurscht.
Die ganzen Loops in Modulen laufen auch ohne Highlighting gut.
Da würde ich mal ganz lieb mit Aldus reden.
Dietmar
-
@Doc.
Hast Recht.
Ich werde dafür ein Featurerequest aufsetzen, davor aber eine bessere Erläuterung ausklügeln, sodass die gleich die Zusammenhänge erkennen können (wie man es einsetzen kann, für wen das gut ist, warum es wichtig ist, wie man WB trotzdem _einfach_hält_ - solche Zusatzfeatures dürfen nämlich bei dem OttoNormalUser nicht zur Verwirrungen führen).
Der Thread wurde eröffnet, dass man sich über die Ideen austauscht und schaut, wie sie bei USERN ankommen.
Und außerdem können Diskussionen viel Arbeit ersparen, weil Ideen vermengt werden können und unnötige Programmierung vermieden werden kann - z.B. wenn hinterher einer noch eine bessere Idee hat.
Die Idee mit dem TRAC und dem Featurerequest ist gut.
Doch ich wünsche noch mehr Austausch darüber hier.
Zeigt doch nur, wie interessant das ist.
@Dietmar.
Nun, ja, wenn Aldus das für Sinnvoll erachtet, dass das Code2 bunt wird.
Mir soll es recht sein.
Gruß,
Stefek
-
Hi,
Doch ich wünsche noch mehr Austausch darüber hier. Zeigt doch nur, wie interessant das ist.
Naja. Bei den meisten Threads in letzter Zeit sehe ich vor allem die Tendenz dass viele verschiedene (oft auch nicht Thread relevante) Themen in einem Thread gepostet werden. Manchmal auch noch Deutsch und Englisch gemischt. Auch dieser Thread ist nicht leicht zu folgen. Nimmt man sich die Zeit alles von vorne bis hinten durchzulesen, dürften sich die Kernaussagen aus 43 Posts in 3-4 Sätzen zusammenfassen lassen.
Bei den Seitenoptionen (Menü, Seitentile, URL) und Mehsprachigkeit darf man sich ruhig auch von anderen CMS inspirieren lassen (nicht Joomla oder Typo3).
Also ne kleine Zusammenfassung um was es hier eigentlich geht, wäre sicherlich nicht schlecht und dann auch einen Feature Request dazu.
Doc
-
Wo ist das Problem, zusätzliche Felder in den Tabellen anzulegen und die dann vorläufig über ein Admintool zu verwalten. Wenns läuft und sinnvoll ist, kommt bestimmt auch die Bereitschaft, die Felder fest unter Seitenoptionen einzubinden.
Nur im Moment wird da eigentlich alles nur kaputt geredet. Man kann immer um den Core herum programmieren. Nichts ist unmöglich.
Dietmar
-
Stefek,
genau deswegen habe ich es nochmal hochgeholt.
Ich denke das es aufjedenfall sinn macht
Seitentitel, Menütitel, Menü ALT, und Pagename (Speichername) finde ich äusserst sinnvoll für SEO
Nur wenn der Thread in der versenkung verschwindet, und keiner nen request stellt, wird es nix mit den neuerungen in den kommenten versionen.
Währe nur noch zu überlegen, wie man es mit den Updates und alten Versionen handled mit den neuen Feldern.
Seitentitle - bleibt
Menütitle - bleibt auch
Menü ALT - Evtl. übername vom Seitentitel - danach von hand änderbar
Pagename - übernahme vom menütitle - danach durch User änderbar
Letzterer ist wahrscheinlich das hauptproblem wegen den Suchmaschinen :-((((
Gruß Bastian
P.s. das mit den Sprachen denke ich, sollte man einzeln behandeln, da anderes bzw. eigene Thematik
-
So jetzt habe ich mir das erstmal als Featurerequest gespeichert. Das mit den Sprachen fliesst aber auch da hinein. Hatte mal den Vorschlag aufgenommen ein Feld page_code anzulegen. Wir werden sehen, was die 2.9er bringt. Auf jeden Fall werde ich jetzt mal alles sammeln. Nicht jeder schreibt ins Ticket.
Dietmar
-
Danke Dietmar.
@Basti: sehr gut gemacht
@Doc: ja, ich unterhalte mich gern. Und?
Stefek
-
Hallo Zusammen,
ich finde diese Ideen sehr gut, besonders die für die SEO
(alt für die Menu links, den Seiten-Namen selbst vergeben - nicht den Menütitel nutzen, ...... )
Zum Sprachen Problem:
währe es nicht denkbar, die Sprachenumschaltung anhand der Seiten ID zu machen?
Bei den Seiteneinstellungen ein Feld, in dem man die ID der Seite in der anderen Sprache einträgt???
Bei mehreren die ID mit komma trennt? Die Reihenfolge der ID's müsste natürlich festgelegt werden.
Gruß Bastian
Das ist viel zu umständlich und zu aufwendig für die Pflege - wenn du eine neue Sprache hinzufügst, musst du dann ja an den Seiten in den anderen Sprachen wieder ändern.
Eine einfachere Lösung existiert schon, auch wenn sie von manchen Leuten fleißig ignoriert wird.
http://wbdemo.heysoft.de/pages/de/mehrsprachige-websites.php (http://wbdemo.heysoft.de/pages/de/mehrsprachige-websites.php)
-
Hallo Frankh,
es wird nichts ignoriert, es gibt da mehrere Lösungen und man wird alles genau durchtesten müssen, um sich dann für eine Lösung zu entscheiden. Oder wirft alles in einen Topf, nimmt von jedem das Beste und programmiert die Eierlegende Wollmichsau. Wir developen alle für das gleiche Project und ziehen hoffentlich an einen Strang.
Dietmar
-
Hallo,
eine verbesserte Sprachunterstützung ist unter anderem deswegen nicht in WB 2.8 zu finden, weil es derzeit mindestens 3 Ansätze gibt dies zu verwirklichen (FrankH, Luisehahne, doc). Alle haben ihre Vorteile und Nachteile. Aufgabe der künftigen devs wird es wohl sein das beste aus allen diesen Ideen (eierlegende Wollmichsau) in WB zu integrieren. Denn bei einem sind sich ja gott sei dank alle einig, im Bezug auf Umschaltung zwischen Sprachen bei mehrsprachigen Seiten ist dringender Handlungsbedarf angesagt.
Matthias
-
Hallo Zusammen,
ich hole es noch mal nach oben, da an anderer Stelle ein neuer Thread aufgemmach worden ist,
der denn ziemlich gleichen Hintergrund hat.
https://forum.WebsiteBaker.org/index.php/topic,10661.0.html (https://forum.WebsiteBaker.org/index.php/topic,10661.0.html)
So jetzt habe ich mir das erstmal als Featurerequest gespeichert. Das mit den Sprachen fliesst aber auch da hinein. Hatte mal den Vorschlag aufgenommen ein Feld page_code anzulegen. Wir werden sehen, was die 2.9er bringt. Auf jeden Fall werde ich jetzt mal alles sammeln. Nicht jeder schreibt ins Ticket.
Dietmar
Hast du den Feature Request auf der Projektseite gestellt? Habe nichts dergleichen gefunden.
MFG Bastian
-
Nun, eigentlich ist der andere Thread älter.
Diesen hier habe ich aufgemacht, weil es mir aufgefallen ist,dass es mehr Felder sind, als nur das eine, dort besprochene, ist.
Das Thema ist immer noch wichtig.
Die Ideen für die nächsten Versionen sollten immer besprochen werden.
Gruß,
Stefek
-
Eigentlich könnte man das wirklich leicht lösen, auch wenn das Backend dann nicht sooo komfortabel ist. Man braucht nur eine Tabelle mit drei Feldern: page_id, page_attribute, value.
Bei den Seitenoptionen dann einen Knopf "Attribut hinzufügen". Man bekäme dann zwei Eingabefelder, wo man im ersten den Namen des gewünschten Attributes und im zweiten halt den Wert desselben eintragen kann.
Ist dann halt nicht so bequem (keine Vorgabeliste für mögliche Attribute etc.), aber leicht umzusetzen. Als Zwischenschritt sicherlich ganz brauchbar.
-
Hallo WebBird.
Wenn dies über Admin/Optionen/erweiterte Optionen zuschaltbar wäre, würde es im Backend nicht stören.
Diese zusätzlichen Felder sind für zeitgemäßes Webdesign wichtig.
Gruß,
Stefek