User tests: Successful: Unsuccessful:
Another take of #32146 .
Keep the functions endTab, addTab, endTabSet, startTabSet, renderModal, endSlide, addSlide, endAccordion, startAccordion
with the same selector as Joomla 3. No B/C break here!
For the functions toast, tooltip, tab, scrollspy, popover, modal, dropdown, collapse, carousel, button, alert
there is no default CSS Selector and also the methods can accept any valid CSS Selector. How this works? Here's an overview:
Try to select another component in a menu administrator/index.php?option=com_menus&view=item&client_id=0&layout=edit&id=101
Accordion still works
Try to edit the tinyMCE options, tabs for the sets still work
Edit an article, Modals for user and images still work
Dropdown like save as (toolbar) and user menu (top bar) still work
Status | New | ⇒ | Pending |
Category | ⇒ | Administration Layout Libraries Modules Front End |
Labels |
Added:
?
|
Category | Administration Layout Libraries Modules Front End | ⇒ | Administration Front End com_users Layout Libraries Modules |
Are those preg_replace still necessary, and are they right?
These are fail safe fuses. Lets take public static function addTab($selector, $id, $title) :string
as an example:
in J3 it expects an ID (without . or # )
joomla-cms/libraries/cms/html/bootstrap.php
Lines 790 to 805 in e6cbda0
.
or #
will break badly
In J4 we make sure that .
or #
will not be passed as a selector to the layout (it will break things if we don't check) https://github.com/joomla/joomla-cms/pull/32357/files#diff-e89418d6aa7e99964d6509d6b9ccb765ec5b9edd3482bd8ad08c29f29d2202e5R817 and https://github.com/joomla/joomla-cms/pull/32357/files#diff-74bf0060b6aa5eed515b6e29b0b4242ab49049d00b711b755f4c96488407fd53R16
Maybe overprotective but better safe than sorry
@dgrammatiko But why is that ?
modifier in the pattern only applied to the \.
but not the #
? Or isn't that a modifier but a literal ?
?
@richard67 unless I got it totally wrong /^\.?#/
should be returning either .
or #
at the beginning of the string. I think I just copied that from some method in the J3 repo
@richard67 unless I got it totally wrong
/^\.?#/
should be returning either.
or#
at the beginning of the string. I think I just copied that from some method in the J3 repo
So a .
or #
at the beginning shall be removed? If so, then your pattern seems not to do that, at least not when I've tested with diverse online tools. A #
was removed, but a .
not. If it shall be that one .
or one #
at the beginning (and only there) shall be removed, then I would think pattern /^[\.#]/
is the right one.
@richard67 fair enough, I'm not a regex expert but I'll take your word on this one. Changes done in 67e7c07
@richard67 fair enough, I'm not a regex expert but I'll take your word on this one. Changes done in 67e7c07
Then I only can hope I was not wrong ;-)
Category | Administration Layout Libraries Modules Front End com_users | ⇒ | Administration JavaScript Repository NPM Change Front End com_users Layout Libraries Modules |
Labels |
Added:
NPM Resource Changed
|
You can test it with DPCalendar from here https://joomla.digital-peak.com/download/dpcalendar/dpcalendar-8-0-3?format=html
I have tested this item
Without the patch the following system tests have been broken:
All of them do work now with the pr.
I have tested this item
Status | Pending | ⇒ | Ready to Commit |
RTC
See #32259 (comment)
@infograf768 So remove RTC?
@infograf768 #32259 is something specific to the media field, nothing touched here could solve that problem
@infograf768 #32259 is something specific to the media field, nothing touched here could solve that problem
@dgrammatiko Do you think you can fix that with another PR?
Do you think you can fix that with another PR?
It should be a simple conditional for the user access level (if not allowed to edit just display the image or don't display anything at all) it's not even js related.
I agree it's not related to this patch. Was just responding to #32259 (comment)
Posting something like See #32259 (comment)
without context is very confusing, as both I and @richard67 thought that this was an unwanted side effect
No, all fine, it's only me being paranoid sometimes when it's related to software ... I consider everything possible.
@dgrammatiko fix the conflicts from the BS beta 2 merge - one test to ensure that new beta doesn't change anything and good to merge
Labels |
Added:
?
|
A first test run failed because the change event is not triggered in the user field. But can also be an issue in our end. Will test over weekend.
I have tested this item
So we have two successful tests here.
Status | Ready to Commit | ⇒ | Fixed in Code Base |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2021-02-12 16:06:17 |
Closed_By | ⇒ | wilsonge |
Thanks guys
@dgrammatiko Are those
preg_replace
still necessary, and are they right?