Docs developer list
Using Jamroom
The list of developer docs has become horizontal (don't think it looked like that last time I saw it):
https://www.jamroom.net/docs/list
updated by @ultrajam: 08/14/14 07:31:14PM
Forum Activity for @ultrajam
Using Jamroom
The list of developer docs has become horizontal (don't think it looked like that last time I saw it):
https://www.jamroom.net/docs/list
updated by @ultrajam: 08/14/14 07:31:14PM
jrElastic accordion
Design and Skin Customization
Take a look at the left column modules menu in the ACP
profile_option.tpl
Jamroom Developers
Ah, I hadn't looked at the admin output.
I think it would be better if the templates all used a similar structure for similar pages (there are quite a few variations) but I can see that would be a difficult "fix" for something which already works.
Might be a good idea to use a class rather than an inline style though, that way it can be removed/adjusted in the css rather than using jquery or smarty in a skin template override.
profile_option.tpl
Jamroom Developers
I'm testing on a custom module, but it occurs on any module with a profile view which is not named "default".
So the jrStore sales pages, jrForum settings tab and categories tab are ones I have noticed, but it will occur if you add a profile view function to any module e.g. profile_view_jrBlog_test
jrStore - css and js files missing
Jamroom Developers
jrStore sale_list.tpl line 3:
<div class="block_content" style="font-size: 0.7em">This can cause problems if you add any other content in the page apart from the data table (eg breadcrumbs etc).
Imo, better to move the inline style to the dataTables_wrapper css class
.dataTables_wrapper {
font-size: 0.7em;
}
profile_option.tpl
Jamroom Developers
If I use the block > block_content structure on a page which uses profile_option.tpl I get an extra 12px padding on the col9 last div - those pages then look different when clicking between tabs and other (item_list etc) template profile pages(in jrElastic). The inline style seems to be doing the same thing as the div class="block" which wraps the other "col9 last" pages on the profile.
Nothing to check out really, just seems a bit weird to need to use a different class structure for different profile pages (which are visually the same - title followed by content).
I havent tried it, but would it work to use class="block" on the div in profile_options.tpl rather than an inline style? But if you did that, why not remove the div from profile_options.tpl altogether and use the normal block > block_content divs in all the profile templates?
profile_option.tpl
Jamroom Developers
Giving up on this for now, but think I've found a way around it (not widely tested though)
A bit counter intuitive, but you need to use a different structure for profile pages with an option in the url (if you wnat your profile pages to all line up).
"Normal" structure:
<div class="block">
<div class="title">Title Stuff</div>
<div class="block_content">The Content</div>
</div>For profile pages which use the profile_option.tpl:
<div class="block_content">
<div class="title">Title Stuff</div>
The Content
</div>profile_option.tpl
Jamroom Developers
I'm having trouble figuring out profile_option.tpl
I have a module which uses tabs and when I switch to jrElastic I'm getting the inline margin:12px added in places where it isnt needed. That isn't a problem in my skin as the div is simply removed in the overridden template.
It looks like the only reason the profile_option template is there at all is to add a div with a 12px inline margin for tabs other than the default.
If there is a reason for that please explain and I might be able to figure out how to get around it.
Thanks
updated by @ultrajam: 08/04/14 11:47:57AM
SOX, LAME, and other audio functions
Jamroom Developers
Your GRiD number is created in the create_save function:
// media needs a unique grid id
$_core['audio_grid'] = xtSong_create_media_grid($_rt['_profile_id'],$_rt['_item_id']); //userId, songId
jrCore_db_update_item('xtSong',$aid,null,$_core);You already have the file from this line:
$_fl = jrCore_get_uploaded_media_files('xtSong','audio_file',$_user['user_active_profile_id']);So you'd use $_fl for any functions that require the file (bpm detection etc) and then save that to the song data in the db.
For anything like additional format conversion, you might do that in the create_save function as well, or possibly in a save_media_file listener. (look at jrVideo_save_media_file_listener for an example of that (it runs the jrCore_get_media_file_metadata function), jrAudio runs the same jrCore_get_media_file_metadata function from the create_save function.
In a nutshell, jrAudio doesn't do any of the things that you wnat it to do, so you need to write the custom functions that do those things, then run those functions in the xtSong_create_save function, have the functions return the info that you need to save to the db, and then add it to the $_rt array when the item is created, or to the $_core array if you need the item id before you run your function (like it does with the GRiD generation where the song id is needed in oreder to create the GRiD).
I don't have the first clue as to how to hand any processing off to a second server.
updated by @ultrajam: 07/02/14 03:55:55PM
