UPDATES EasyBlog 6.0.11 Released! Update to the latest version now!

Helpdesk

Your Time
Our Time
Response Time
24 — 48 hours
We strive to provide the fastest ever response possible. However, we are not super beings.

Allow at least 24 — 48 hours
  Support is offline
Our team is away during the weekend. Some answers may already be available on our documentation

Rest assured that we will get back to your posts as soon as the week starts!
  Support is offline

cid field in comments table

Hugh Messenger · ·
12:05 PM Tuesday, 03 January 2017
None
Hi,

I'm lead dev for Fabrik (an app builder extension). I'm writing a Komento integration.

The problem I've run into is that the assumption underlying integrations is that the app has a single "article" table like #__categries, or vm_products, or k2_items, etc. So the 'cid' field in the main Komento #__komento_comments table is an INT, essentially expecting it to be the primary key on the app's single "article" table.

In Fabrik, we don't have a single "article" table. Our equivalent of categories / articles are "lists" (arbitrary database tables) and "row ids" (PKs in the tables). And any given Fabrik app can have dozens of different lists. And of course the rowids of those lists (tables) are not unique - they are all auto-inc PKs starting at 1.

So for Fabrik to work with Komento, the 'cid' needs to hold two ids - the list and the rowid.

As far as I can tell, the only change that needs to be made in Komento for this to work is the 'cid' field in #__komento_comments table needs to be a VARCHAR, not a LARGEINT. That way, I can set the 'cid' in my item to listid:rowid (like 17:147), and my various KomentoComfabrik class methods like load() can just split out the two ids I need from that.

I've tested locally, changing 'cid' to VARCHAR(64), and it doesn't seem to adversely affect Komento at all, and my integration then works perfectly.

I know changing field types is not something we like doing as extension devs ... but I'm hoping you might put it on your list for things to consider.

-- hugh
The replies under this section are restricted to logged in users or users with an active subscription with us