| Sergeich |
|
|---|---|
|
I suggest to compose some common rules for page structure and properties.
---------------- It seems like "more" bbcode will be gone and replaced by short article description. I think we should add a new field with bbcode support and editor. And we also keep SEO in mind when making it. There is just one field required for SEO - keywords. All the rest code already exists. Everything can be done immediately with minimal effort. And the third thing that bothered me some time ago is article length limit. We need to decide how to support multipage documents with minimal loss. As for me, I don't even know where to start with it. :) |
|
Dieser Beitrag wurde von Trustmaster (am 2. September 2008, 19:07, vor 15 Jahre) bearbeitet |
| Lombi |
|
|---|---|
|
Keywords were usually handled in the page_extra5 field (at least they were default at that for several plugs that were using keywords)
Also won't this more dissapearance by an incredible annoyance? Hundreds of thousands of pages to change (okay, i admit that it could be done by a script but still - an annoyance to do over multiple domains) <a href="http://www.domenlo.com">Surreal Art</a>
|
| Sergeich |
|
|---|---|
Keywords were usually handled in the page_extra5 field (at least they were default at that for several plugs that were using keywords)I use page_extra1, John Smith - page_extra2 ... We need to highlight once these goals under a special box and forget about the problem of compatibility in the future. |
| Lombi |
|
|---|---|
|
I agree. Maybe an extra step in the installer like "which field are you using for keywords" - then have them imported into page_keywords ... or page_tags
<a href="http://www.domenlo.com">Surreal Art</a>
|
| Trustmaster |
|
|---|---|
|
It's better to have it a new page_keywords field (by the way, should it be TEXT or VARCHAR(255) is enough?). And all existing keywords can be easily migrated with a simple SQL query.
May the Source be with you!
|
| Orkan |
|
|---|---|
|
Alternatively, we could store all tags in a separate db table. Then, in another table we will keep tag <-> resource assignments.
Yah, I know thats 2 extra tables, but then it is very easy to implement such features like "Tag Cloud" or "auto suggest" Perl - the only language that looks the same before and after RSA encryption.
|
| Trustmaster |
|
|---|---|
|
This will enable tags but will slow down keyword search. A double-edged weapon.
May the Source be with you!
|
| Orkan |
|
|---|---|
|
yah, the keyword search... I have a question on the PHP/mySQL level:
I may be wrong, but how would you perform a search for a keyword "wind" on these two examples: 1: "abc, wind" 2: "windows, xyz" Perl - the only language that looks the same before and after RSA encryption.
|
| Kilandor |
|
|---|---|
|
It should be a Text Field No question, varchar 255 would be a silly needless limitation, that depending on the site/owner could easily be passed
For searching, I prob don't knwo best ways, but 2 options are fulltext, or %wind% which would return both. I don't see much need for storing the keywords in a seperate db? |
| Orkan |
|
|---|---|
|
Oops, we will soon have a triple-edged weapon with this Text field.
Apart from a few slight problems, ie. how to write by hand so much keywords... but how we gonna deal with performance? Well, Im impressed by how tags evolve during past few years. Just look at: google, delicious, devianArt, imageshack etc,etc... to see how they modeled tag collections. Im pretty sure they dont use simple text-fields for that. Tag Clouds is the must-have feature for many websites. How you gonna track clicks without separate db ? Of course, there is no need to put this into core, but definitely we should consider making an official plugin to handle tag collections, IMO Perl - the only language that looks the same before and after RSA encryption.
|
| Trustmaster |
|
|---|---|
|
TEXT fields take more space and work slower.
Tags are must have, no doubt. But keywords are needed too. Keyword search on tag DB is possible of course, just need to try implementing them combined. Migrating existing keywords and automated tools is a headache but possible. May the Source be with you!
|
| Lombi |
|
|---|---|
|
well i might be shooting in the dark here but i use the same keyword field for both keywords (which i feed to meta keywords) and for generation of a tag cloud (which means stripping the commas and removing duplicate words)
And 255 chars is way too little for keywords if you're doing really extensive keywording... <a href="http://www.domenlo.com">Surreal Art</a>
|
