cotonti.com : [Incubation] Seditio pages reviewed

Lombi

Thu, 04 Sep 2008 05:51:41 -0000

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

Trustmaster

Thu, 04 Sep 2008 02:42:26 -0000

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.

Orkan

Thu, 04 Sep 2008 02:28:09 -0000

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

Kilandor

Wed, 03 Sep 2008 23:25:37 -0000

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

Wed, 03 Sep 2008 22:20:36 -0000

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"

Trustmaster

Wed, 03 Sep 2008 21:42:56 -0000

This will enable tags but will slow down keyword search. A double-edged weapon.

Orkan

Wed, 03 Sep 2008 21:04:08 -0000

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"

Trustmaster

Wed, 03 Sep 2008 20:32:11 -0000

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.

Lombi

Wed, 03 Sep 2008 20:30:08 -0000

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

Sergeich

Wed, 03 Sep 2008 00:16:24 -0000

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

Tue, 02 Sep 2008 20:16:27 -0000

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)

Sergeich

Tue, 02 Sep 2008 01:49:29 -0000

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