Can you add a deprecated log message to the getControlGroups and getControlGroup functions?

Done

Now go test this so I can squeeze it into J3.2.3

Just a junk test comment from phone, see if the comment editor works on Android with long run on sentences that just never seem to end and take up the entire box with our a full stop which for some reason I've seen cause issues on others github and bootstrap based systems but so far this one seems to handle it OK and is scrolling up one line as needed OK I can stop typing now.
You may blame the J!Tracker Application for transmitting this comment.

@test (with Patchtester Component)

I can't see issues at the edit views for this components after the patch:
weblinks, contacts, content and newsfeeds

Since we have two valid tests i move the Tracker to RTC.

Thanks George!
You may blame the J!Tracker Application for transmitting this comment.

@zero-24 Sorry to be a pain I just made a very small tweak to the PR to make it a bit more customizable (just moving the layout to be a class variable rather than hardcoded) could you please very quickly test again!

@wilsonge

#test (with Patchtester Component)
Can't see a problem with this patch at the edit views of:
weblinks, contacts, content and newsfeeds.

Thanks @wilsonge again.

You may blame the J!Tracker Application for transmitting this comment.

tested and works fine

@wilsonge

George, could you see how this plays with #3127 as it seems we won't have support for it with this change? Could you check if we can easily add it to your changes, since the other PR was about to be commited :-)

You'd have to pass the relevant values into the JLayout. Maybe pass in options. I had a hideLabel I'd just passed in. But it's not going to be a 10 second job - but it won't be hard either

@wilsonge

Sorry for reviewing this so late, but I have a couple of questions more.

1) If someone overrides the way forms are rendered, won't that break admin templates, since they rely on certain output?
2) Is there any reason you explicitely check in field.php:901 for a hidden label, instead of passing the whole options array? By passing the whole options array, you leave it open to people to use any option they want in the layout
3) In renderfield.php:23, condition can be replaced with empty($displayData['hiddenLabel'])), as it does exactly the same check, though I'd rather have that changed based on feedback from 2) if possible.
4) I will check how to add "showon" feature again based on the answers :)

1) No because JLayouts are template specific overrides
2) I kinda regret not just passing in options - we haven't had a release of the CMS yet so if you want to change that as part of your showon changes you can do that without breaking B/C
3) Umm as long as you can differentiate between the value being set to false and the value being just not filled in in which case we should show it then yeah it's fine
4) Cool. I can try and PR the stuff into your branch if you want

Ok, cool, I will make a new PR, hopefully asap so we can get it done on time for the release

Sorry for being a pain :)

On 26 March 2014 18:56, Marko D notifications@github.com wrote:

Ok, cool, I will make a new PR, hopefully asap so we can get it done on
time for the release

Reply to this email directly or view it on GitHub#3209 (comment)
.

Umm, are you sure about 1)?

I just installaed latest staging, edited layout file to change output, and got broken backend when I opened some random module. Which seems expected, since in libraries/joomla/form/field.php:903 you render layout, and that's what extension parameters are rendered with on the backend

If you edit the layout file you will. But you don't - you do a template
override of layout like here:
https://github.com/joomla/joomla-cms/blob/staging/administrator/templates/hathor/html/layouts/com_messages/toolbar/mysettings.php

And never edit the layout file in the layouts folder.

On 26 March 2014 19:30, Marko D notifications@github.com wrote:

Umm, are you sure about 1)?

I just installaed latest staging, edited layout file to change output, and
got broken backend when I opened some random module. Which seems expected,
since in libraries/joomla/form/field.php:903 you render layout, and that's
what extension parameters are rendered with on the backend

Reply to this email directly or view it on GitHub#3209 (comment)
.

Something must have came into me when I left the previous comment...

Don't worry I have those moments far too often :D

On 26 March 2014 20:00, Marko D notifications@github.com wrote:

Something must have came into me when I left the previous comment...

Reply to this email directly or view it on GitHub#3209 (comment)
.

Me again. Are you by mistake calling deprecated methods in form.php on lines 682 and 705 or am I missing something? I also got confused why I got nothing from JLog if it was true when I turned on maximum error reporting, but it showed up after changing in log.php:168 exclude condition to true (though nothing in logs folder still). Is there any way I can make see JLog entries from the system without changing this default parameter, how is it supposed to work?

In the meantime, I added the showon feature, and I also added support for hiddenLabel on xml level. Please check #3379

Yes I am in the form.php file. I've already fixed that in a later PR though.

To get deprecated methods to show you need to turn it on in the debug plugin :) you shouldn't need to edit log.php

I know I am not supposed to edit it, but I cannot get it to work either. Debug plugin is on, Log priorities set to All, and Log categories is empty, which from the field description means "If empty, all categories will be shown". But I do not get notice for 'deprecated' errors.

In the debug plugin in the logging section - you've turned on the "Log deprecated API" parameter right?

Ah, no, I didn't see that option at all. I often don't see that there are extra parameters in Joomla 3 :/ Thank you George.