profile_option.tpl

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


--
¯\_(ツ)_/¯ Education, learning resources, TEL, AR/VR/MR, CC licensed content, panoramas, interactive narrative, sectional modules (like jrDocs), lunch at Uni of Bristol. Get in touch if you share my current interests or can suggest better :)
updated by @ultrajam: 08/04/14 11:47:57AM

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:

For profile pages which use the profile_option.tpl:



--
¯\_(ツ)_/¯ Education, learning resources, TEL, AR/VR/MR, CC licensed content, panoramas, interactive narrative, sectional modules (like jrDocs), lunch at Uni of Bristol. Get in touch if you share my current interests or can suggest better :)

Sorry Steve - haven't had a chance to check this out yet. Can you let me know what you mean by "if you want your profile pages to all line up"?

Thanks!


--
Brian Johnson
Founder and Lead Developer - Jamroom
https://www.jamroom.net

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?


--
¯\_(ツ)_/¯ Education, learning resources, TEL, AR/VR/MR, CC licensed content, panoramas, interactive narrative, sectional modules (like jrDocs), lunch at Uni of Bristol. Get in touch if you share my current interests or can suggest better :)

I'm not a fan of things not working like you would think they should work, so I will check this out. What module are you testing with?

Thanks!


--
Brian Johnson
Founder and Lead Developer - Jamroom
https://www.jamroom.net

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


--
¯\_(ツ)_/¯ Education, learning resources, TEL, AR/VR/MR, CC licensed content, panoramas, interactive narrative, sectional modules (like jrDocs), lunch at Uni of Bristol. Get in touch if you share my current interests or can suggest better :)

Yeah right.

I made profile_view_jrBlog_test() as:

and the result is:

mmmm. It was probably put there for a reason. Wonder what that was.

profile_tabs.tpl also has a margin:0 12px;

My first suspicion was so that modules don't have to think about profiles css structure to line up with the layout. Looking more now.

Looking at all the other modules profile_view_* functions that are not _default seam to share the common trait of using the admin area structuring for the output.

The:
jrCore_page_banner()
jrCore_form_create()
jrCore_form_field_create()
etc...

Where as the majority of the _default functions use the jrCore_parse_template() function to render a template.

It seams to me that is what the 12px border is for. to bring the admin style stuff into alignment with the layout for that skin (jrElastic).

Don't think forcing a css class structure is the right way to go. (so developers have to come in line with how the skins CSS is done.) That would seam to limit developers ability to build whatever.

What do you reckon?

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.


--
¯\_(ツ)_/¯ Education, learning resources, TEL, AR/VR/MR, CC licensed content, panoramas, interactive narrative, sectional modules (like jrDocs), lunch at Uni of Bristol. Get in touch if you share my current interests or can suggest better :)

Yeah inline is definitely not what we want - I'll do some testing here, as off the top of my head I cannot remember why it was done this way.

Thanks!


--
Brian Johnson
Founder and Lead Developer - Jamroom
https://www.jamroom.net

That inline style is just the style that that skin has decided to use. In a different skin, the different skin creator could choose to use a class.

The template is:
/skins/jrElastic/profile_option.tpl

So ....... ah, I see what you mean. You could define a class over-ride in your modules CSS file to over-ride the skins settings. Yeah a class would be better. More options.