[geeklog-devel] Geeklog Topics and Blocks

Vincent Furia vfuria at gmail.com
Mon Aug 22 17:05:39 EDT 2011

First the easy part. Defining the tables:

   1. Remove 'tid' from the story table.
   2. Create a new table "topic_assignments". It should have columns "type"
   varchar(30), "sid" varchar(40), and "tid" varchar(20). It's primary key
   should be on "tid" and with a INDEX on "type" and "sid" (this key could also
   just be on sid).
   3. The topics table is sufficient as is, though that depends on the full
   set of features you want to change.

The underlying code changes get complicated. Here is what I recall looking
at originally, though I'm sure there is more that will have to be modified
to incorporate the changes. Since you're implementation allows a single
article (or other item) to be belong to multiple topics, you're changes are
going to be more extensive than what I had looked at. At a minimum you're
going to want to look at lib-common.php, article.php,  and lib-security.php.

   1. COM_siteHeader may need some mods to recognize when you are looking at
   plugin/block/etc that is associated with a specific topic. Also,
   2. COM_showBlocks will have to be modified to handle a topic array as
   well as a single topic. Most calling functions to COM_showBlocks functions
   will also need to be modified to handle multiple topics.
   3. COM_topicArray will have to understand the new underlying database
   4. SEC_hasTopicAccess probably doesn't need to change, but keep an eye on
   5. COM_rdfUpToDateCheck will need to be expanded to handle topic feed
   updates for non-article types.
   6. COM_featuredCheck assumes tid will be in the article table. You'll
   also have to figure out how you want to handle featured article flag on
   stories with multiple topics, this could get really confusing if not taken
   into account at the start.
   7. COM_adminMenu will need to handle topic assignments. Again, it assumes
   tid in the article table.
   8. Everywhere COM_getTopicSQL is called will need to be rethought (and
   the function itself will probably go away). That code currently generates an
   "IN" clause against the tid in the article table. All queries that use it
   will have to do a double join to the topics table and topic_assignments
   table. I imagine this is where A LOT of the work for this project will be
   9. COM_emailUserTopics will need some mods since you don't want the
   informational email to repeat articles. Also, you might want to add a plugin
   API for plugin items be included in topic emails.
   10. Obviously a new interface will be required to submit/administer
   articles with multiple topics. Some generic functions here will make it easy
   to add topic support to other plugins.
   11. Webservices may be impacted, though I haven't looked at that code at
   all to even make an educated guess as to how much (or even if they would be
   12. I think story.class.php will require extensive modifications, though
   it didn't exist when I first looked into modifying topics. I'm sure my notes
   on article.php are useless for the same reason...

That should get you started. It's a pretty big undertaking. You might want
to reconsider implementing subtopics, with all the work needed already the
extra cost wouldn't be great (though I do understand your desire to limit
the scope at least a little bit).

It's a shame we didn't do GSOC this year, this probably would have made a
great project for a summer intern...


On Mon, Aug 22, 2011 at 07:28, Tom <websitemaster at cogeco.net> wrote:

> >Any change that modified the database would require quite a bit of work
> (as my suggestion in the first paragraph would). If you end up going with
> any of these ideas, I had >thought out quite a bit more detail if you want
> it.****
> ** **
> Sure. J****
> ** **
> ** **
> *From:* geeklog-devel-bounces at lists.geeklog.net [mailto:
> geeklog-devel-bounces at lists.geeklog.net] *On Behalf Of *Vincent Furia
> *Sent:* August-21-11 7:20 PM
> *To:* Geeklog Development
> *Subject:* Re: [geeklog-devel] Geeklog Topics and Blocks****
> ** **
> I had done some thinking on this several years ago. The most flexible
> design I came up with is using "tag" style backend. Instead of having tid's
> associated with stories, there would be topic_assignments (or some better
> named...) table allowing a many-to-many relationship between stories (or
> blocks, or plugins, etc) and topics.****
> ** **
> I went so far as to also consider how to handle sub-topics. Easy way: you
> could define topic relationships by having a topic separator (e.g. "-" or
> "/") in the topic name. Hard way: create a hierarchal data structure in the
> database (parent child relationship, or tree representation similar to how
> comments are not handled). The latter design would allow more flexibility,
> though the former would be significantly less work to implement.****
> ** **
> Any change that modified the database would require quite a bit of work (as
> my suggestion in the first paragraph would). If you end up going with any of
> these ideas, I had thought out quite a bit more detail if you want it.****
> ** **
> -Vinny****
> ** **
> On Sun, Aug 21, 2011 at 14:31, Tom <websitemaster at cogeco.net> wrote:****
> I have started to do a bit of research/work on my feature request about
> allowing topics to be associated with other objects like staticpages, etc.
> http://project.geeklog.net/tracking/view.php?id=1155
> I was also thinking about (I haven't decided to tackle it yet):
> - Allowing blocks to be assigned to one or more topics and not just one or
> all.
> - Allowing stories (and other objects)  to be assigned to one or more
> topics.
> Does anyone have any thoughts or opinions...
> Tom
> _______________________________________________
> geeklog-devel mailing list
> geeklog-devel at lists.geeklog.net
> http://eight.pairlist.net/mailman/listinfo/geeklog-devel****
> ** **
> _______________________________________________
> geeklog-devel mailing list
> geeklog-devel at lists.geeklog.net
> http://eight.pairlist.net/mailman/listinfo/geeklog-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist8.pair.net/pipermail/geeklog-devel/attachments/20110822/8b3545db/attachment.html>

More information about the geeklog-devel mailing list