Zusätzliche Felder unter Seitenoptionen

[Stefek]

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)

[susigross]

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.

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.

[chio]

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.

[Luisehahne]

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

[susigross]

@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 

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...

[WebBird]

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.)

[WebBird]

"...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.

[Luisehahne]

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.

[susigross]

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.

[Stefek]

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).

[gelöscht durch Administrator]

[Luisehahne]

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

[susigross]

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.

[mr-fan]

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...

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

[Luisehahne]

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

[susigross]

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.

[WebBird]

@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?

[WebBird]

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.

[Luisehahne]

ich bin dafür, dass Matthias sich hierzu auch mal äussert, damit wir das zu Ende bringen was wir angefangen haben.

Gruss
Dietmar

[Luisehahne]

Hallo Webbird,

deine Frage möchte ich noch gerne beantworten

Code: [Select]

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

[WebBird]

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".

[Luisehahne]

Oh s***, stimmt, es war das multilanguage von FrankH. Jetzt gehe ich in Pension.

Gruss
Dietmar

[mr-fan]

Oh s***, stimmt, es war das multilanguage von FrankH. Jetzt gehe ich in Pension.

Gruss
Dietmar

nein bitte nicht.....   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  )

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

grüße martin

[WebBird]

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. Hat doch was gebracht.

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.

[Luisehahne]

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

[Stefek]

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