Using a global $_post in a listener

TiG
TiG
@tig
7 years ago
184 posts
Implementing Discussion Image functionality akin to the Blog List Image so that discussions and blogs all can uniformly hold a designated descriptive image and thus bring another dimension of consistency to the site.

Was able to make a working proof of concept by making changes directly in jrDiscussion. I then reimplemented this properly using a new module (ntDiscussion) and listeners. Think of the new module as a subclass of jrDiscussion. ( Of course I reset jrDiscussion back to its pristine form. )

One of the listeners in this solution seems ugly (to me). I am running it by you folks to see if the practice is sensible for jamroom. The ugly listener is used to invoke the function that saves the newly uploaded Discussion Image:

function ntDiscussion_get_save_data_listener($_data, $_user, $_conf, $_args, $event)
{ ... jrCore_save_all_media_files('jrDiscussion', 'update', $_user['user_active_profile_id'], $_post['id']); ... }

My only concern is that I was forced to access $_post as a global variable to get the information I needed to limit the functionality to the create and update forms for discussions.

Is this an appropriate solution?


--
TiG

updated by @tig: 01/23/18 12:05:41PM
michael
@michael
7 years ago
7,748 posts
 global $_post;
is common to add to functions. also $_user and $_conf are often accessed in this way.

So long as $_user['user_active_profile_id'] and $_post['id'] are validated to be there and are what you are expecting them to be that solution looks fine to me.

The jrDiscussion module uses threaded comments. If your site is slowing down, its probably the cause. Due to it using multiple search="" conditions we have to use a JOIN and that causes a performance hit. Its on the board for a redesign.
TiG
TiG
@tig
7 years ago
184 posts
@michael - Thanks for the confirmation and the info on the future plans for search conditions. Perrie's site is replete with comments and discussions so performance is indeed a top-of-the-mind consideration in what we do. One future consideration is to virtualize the comments tables so that stale comments can be stored in archive tables leaving only the most active comments in the standard tables. The monster challenge here is to find a way to encapsulate comments so that archived comments (when demanded) are seamlessly returned to the client. That is, we would seek a facade that preserves the illusion of a single set of comments tables. Not sure all the areas of jamroom that directly access the comments table so this method may prove to be impractical in jamroom. But it would be a major improvement since the vast majority of stored comments are stale.


--
TiG

Tags