Forum Activity For @Ultrajam

@ultrajam
02/17/14 03:06:50PM
2,589 posts

Show emails for each account

Jamroom Developers

You could add a custom field to the profile settings and use that in the template.

That would be better than using the signup email in most cases, and would be simpler to add to your templates as you can choose the quota in form designer - you don't need to check for quota in your profile template (unless you only want users on a certain quota to see the email address, you'd still need to do that in the template if needed).

@ultrajam
02/17/14 02:43:24PM
2,589 posts

Jr Actions

Jamroom Developers

Is the action being created in the database?

@ultrajam
02/17/14 02:13:34PM
2,589 posts

Jr Actions

Jamroom Developers

You need to run jrAction_save at the point where you want the action to be saved.

jrAction_save function takes these params:

function jrAction_save($mode, $module, $item_id, $_data = null, $profile_check = true, $profile_id = 0)

So you'd need something like this, after the db save and before you'd reset the profile cache:

    $_data['mycustom1'] = 'joe blogs';
    $_data['mycustom2'] = '23';
    $_data['mycustom3'] = 'normal mixes';

    // Add to Actions...
    jrCore_run_module_function('jrAction_save', 'create', 'myModule', $_data);

    jrCore_form_delete_session();
    jrProfile_reset_cache();

The $_data array is where you add your custom stuff, you can save anything you need and then use it in the action template, item_action.tpl:

<span class="action_my_custom_stuff">  {$item.action_data.mycustom1} uploaded {$item.action_data.mycustom2} {$item.action_data.mycustom3} today:</span>

@ultrajam
02/17/14 12:35:23PM
2,589 posts

CSS broken after update/migration

Jamroom Developers

JR5 does standards very well. Using core skin features is optional, and that particular feature uses comments in css as a form of code.

Pretty soon (this year) we have variables in css (goodbye less and sass), but until then we have some of those in JR5 (some smarty works in those css files), plus the skin designer stuff as well.

If you need it all (ability to add css files with comments in, plus the skin designer capabilities) use the standards: add your css files in head as normal, then add an override stylesheet to the core to make some of those css rules user editable in the acp. Best of both worlds, plus a bit more. When you've tried it all out I am sure you will agree.

@ultrajam
02/17/14 12:13:59PM
2,589 posts

CSS broken after update/migration

Jamroom Developers

Developer mode works like this:

Quote:Enabling the "Run in Developer Mode" option will change the information displayed in the "Info" tab for a module to include information about Module Triggers and Listeners, as well as force all template and cache items to be built on every access.

Warning: Enabling Developer Mode will make your system run much slower than normal!
Default: off

Template Variable: {$_conf.jrDeveloper_developer_mode}

That is in the inline help button next to the "run in developer mode" checkbox in jrDeveloper global config. It's the on/off switch which is the first item in jrDeveloper config and you need to check that box in order to run in developer mode. I count that as pretty good notification because I always read the inline help when installing a new module.

If you are already adding the files in meta then all is fine. You only add them through the core if you need them to be minified for you, (you can always add a pre-minified version if you want to reduce the number of calls from meta.tpl, there will be no comments removed).

The main benefit of adding them through the core is that when you format those comments correctly they are used to automatically add user editing of the css in the skin editor - that's the really cool part!!! Check it out! It's an awesome (and easy) way to make your 3rd party css editable in the jamroom acp.
updated by @ultrajam: 02/17/14 12:16:10PM

@ultrajam
02/17/14 11:42:47AM
2,589 posts

CSS broken after update/migration

Jamroom Developers

For files with comments use css_href - then they aren't processed by the core, so you'd want to link to the already minified version. Either in meta.tpl {for a skin) or in a module function using jrCore_create_page_element:

    $_tmp = array('source' => "{$_conf['jrCore_base_url']}/modules/jrAction/contrib/mentions/jquery.mentionsInput.css?v={$_mods['jrAction']['module_version']}");
    jrCore_create_page_element('css_href', $_tmp);

I admit my initial reaction when I first came up against this was exactly the same as yours, but having now used the skin designer I think the trade off (slight inconvenience vs great functionality) is worth it.

@ultrajam
02/17/14 07:54:53AM
2,589 posts

SOLVED - Hide or Delete past events

Design and Skin Customization

Different strokes for different folks, whatever works for you.

I'd remove past events from the jrCore_list pages using search="$smarty.now < $event_date". Then adapt Pauls module to only remove the media from the past event, and make a smarty function to go on each event detail page which shows a "Gig is done . Click here for current gigs" notice. That way you keep all the links to your gigs live (including the internal links in your activity streams), save the server space, and have all the historical data of user activity in case you ever need to have your site valued.

@ultrajam
02/17/14 07:23:33AM
2,589 posts

SOLVED - Hide or Delete past events

Design and Skin Customization

All good stuff!

But what happens when you promote your gigs online, people find it and link to the event page, tweet it etc and then you delete the content after the gig?
People will stop linking to your site if they realise they are going to have a bunch of dead links to remove the day after the gig.

I guess you'll be making a very interesting 404 Not Found page to go with this!