WebsiteBaker Support (2.8.x) > Diskussion über WB (closed)

Zusätzliche Felder unter Seitenoptionen

<< < (7/12) > >>

Luisehahne:
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

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

Stefek:

--- Quote from: chio on June 06, 2009, 10:03:39 AM ---Im großen und Ganzen bin ich mit den vorgeschlagenen Feldern einverstanden.

--- End quote ---
Hört sich gut an.

--- Quote from: chio on June 06, 2009, 10:03:39 AM ---"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.

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

--- Quote from: chio on June 06, 2009, 10:03:39 AM ---Der Link Titel? Der kann auch einfach der Titel sein.

--- End quote ---
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



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.



--- Quote ---Was für mich übrigens auch noch wünschenswert wäre: Das Target nur bei Bedarf und zuschaltbar. Standard: keines.
--- End quote ---
Da gebe ich Dir Recht. Sollte weg als "default".


--- Quote ---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.
--- End quote ---
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

Stefek:

--- Quote from: Stefek on June 06, 2009, 09:03:54 PM ---
--- Quote ---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.
--- End quote ---
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?

--- End quote ---
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

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

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

Navigation

[0] Message Index

[#] Next page

[*] Previous page