Forum Activity for @tig

TiG
@tig
01/26/18 08:02:57PM
184 posts

Custom Banning
Jamroom Developers

@michael

That helped quite a bit. The signature is slightly different but I have it working. The fourth parameter has to be a string (seems any string will suffice) so I passed 'censoring'. The key is the optional fifth parameter. This is where we pass the array to populate the type structure. So the working code is below:

$_opt = array('title' => 'Censored Word',
                  'function' => 'ntCensor_something' );
    jrCore_register_module_feature('jrBanned','banned_type', 'ntCensor', 'censoring', $_opt);

Apparently the only requirement for the function (ntCensor_something) is that it exist. Do you off hand know the purpose of this function? I will experiment, but if you already know .... :)

Thanks again for your help!
TiG
@tig
01/26/18 04:13:09PM
184 posts

Custom Banning
Jamroom Developers

We have a need to censor select words but only on the more public face of the site. The censoring would not be done everywhere. Sounds like a perfect application for jrBanned with a little customization. :)

The docs suggest in various spots the following:

Quote:
The Banned Items module allows you to "ban" specific items from your site:

...

It also includes functionality for other modules to register additional ban "types" for use in the system.

I looked but could not find any examples of this in the code or in the documentation. Admittedly I may have missed it but I just do not see it.

So my question is how would I, for example, register a new type in jrBanned? I presume that I can do so in a module and that would add a new type ( e.g. 'censored' ) so that we could use jrBanned to create a list of censored words and then use jrBanned functions to test them in the specific contexts where we wish to apply them.

I just do not know how to register the new type. FIgured this would be a decent start (this is in the ntCensor module init):

    jrCore_register_module_feature('jrBanned','banned_type', 'ntCensor','censored');

But apparently not.


updated by @tig: 05/02/18 09:50:11AM
TiG
@tig
01/18/18 03:28:44PM
184 posts

Updating Interdependent Modules
Jamroom Developers

@brian

Okay. That means I need to go into maintenance mode. This is a three way dependency so there is no way to order the modules linearly.

Thanks for the quick answer to my question!
TiG
@tig
01/18/18 03:09:30PM
184 posts

Updating Interdependent Modules
Jamroom Developers

I have three modules (let's call them A, B and C) that need be updated together since they are interdependent. That is, the changes in A are required by C and changes in C are required by B, etc.

Question is this: Can I enqueue these three modules and then do a Marketplace UPDATE ALL ITEMS without going into maintenance mode? In other words, will UPDATE ALL ITEMS pause user activity during the update of all three?

Trying to avoid going into maintenance mode for such as brief update. Plus this is good long-term info to have.
updated by @tig: 04/24/18 10:22:48AM
TiG
@tig
01/03/18 02:52:35PM
184 posts

Discussion Form Images
Jamroom Developers

@michael

This is all on the JR hosting site. The site hosts NT production, Alpha and Beta.

I suspect this might have something to do with the changes we made to allow me to package 3rd party modules on Alpha. I copied my user credentials to ACP -> MODULES -> CORE -> MARKETPLACE -> TOOLS -> MARKETPLACE SYSTEMS -> MODIFY. That of course worked and I have been packaging without problems. When I go to that page I see Alpha is listed (but not Beta or Newstalkers). The correlates with my access problem. I can access NT marketplace items from Beta or Newstalkers production but not from Alpha.

At this point, I can just use our Beta site to access jrForum since I am doing my packaging work in Alpha at the moment (temporary). But in the future when I set Beta up to allow me to package modules and skins for migration to production, Beta will be isolated from the NewsTalkers marketplace license too.

Hopefully there is an easy workaround. If not, I can survive.
updated by @tig: 01/03/18 02:53:25PM
TiG
@tig
01/03/18 09:00:50AM
184 posts

Discussion Form Images
Jamroom Developers

One closing question. NT has the ability to install jrForum on the production site, but the alpha site (development area) does not have the option. The Marketplace is asking for payment. Shouldn't the test (staging) areas have the means to install modules according to the master license?

I can install this into production and then copy to the alpha site but I would rather not include modules in production that are not currently being used if at all possible.
TiG
@tig
01/02/18 10:49:48PM
184 posts

Discussion Form Images
Jamroom Developers

@paul

Right now we have the beginning of a uniform abstraction (ntArticle) that covers blogs, discussions and group discussions. I will investigate using jrForum as a functional base for ntArticle going forward. If Brian is correct that adding threading to jrForum is not realistic then I will abandon the idea. As you can tell, I consider it a priority to keep NT as close to JR primary supported functionality as possible. So when making choices I will tend to favor the actively supported side (big picture considerations).

Not really interested in taking on support for a module on the general market. :)

Again, thanks much for your advice.
TiG
@tig
01/02/18 09:22:46PM
184 posts

Discussion Form Images
Jamroom Developers

@paul

I just reread past comments. Your suggestion was indeed for us to use jrForum but Brian thinks we should just continue with jrDiscussion with an archive solution to reduce the db size.

I prefer going with a supported solution so it probably is good for me to investigate jrForum and see how it works. If you have any words of wisdom I am happy to take them.

Thanks for your support.
TiG
@tig
01/02/18 06:50:50PM
184 posts

Discussion Form Images
Jamroom Developers

@paul

I can certainly do that. :)

On a related point, given jrDiscussion is now officially declared obsolete don't you think NT should migrate away from it? I asked this question of Brian and he was not very encouraging. At that time he did not express jrDiscussion being obsolete - more like a road less traveled. Obsolescence should mean that we migrate over to where JR is actively caring for and feeding its functionality. So, asking the same question I asked of Brian, why would NT not migrate to jrForum (or some other choice)?
TiG
@tig
01/01/18 10:00:21PM
184 posts

Discussion Form Images
Jamroom Developers

The following code in jrDiscussion:

function view_jrDiscussion_create_topic_save($_post, &$_user, &$_conf)
{
   ...
    // $id will be the INSERT_ID (_item_id) of the created item
    $id = jrCore_db_create_item('jrDiscussion', $_rt, $_core);
    if (!$id) {
        jrCore_set_form_notice('error', 'An error was encountered creating this discussion - please try again.');
        jrCore_form_result();
    }
    ...

... would be brilliant if it included this after the db_create_item:

   jrCore_save_all_media_files('jrDiscussion', 'create', $_rt['discussion_profile_id'], $id);

... similar to jrBlog:

    // $bid will be the INSERT_ID (_item_id) of the created item
    $bid = jrCore_db_create_item('jrBlog', $_rt);
    if (!$bid) {
        jrCore_set_form_notice('error', 12);
        jrCore_form_result();
    }

    // Save any uploaded media files added in by our
    jrCore_save_all_media_files('jrBlog', 'create', $_user['user_active_profile_id'], $bid);

As you might surmise, I have included support for images in discussions. Updates are no problem since the id is provided, but for creates I cannot seem to find a way to get the new id for a created discussion at the right time to issue the jrCore_save_all_media_files.

The obvious choice (at least given the logic of the function) of tagging off of the jrAction listener fails because of embedded logic that ignores admins making changes.

Any ideas?

updated by @tig: 04/04/18 04:39:47AM
  9