User tests: Successful: Unsuccessful:
Target isClient and isAdmin for version 5.0.
Removes the deprecated functions isAdmin and isSite. See comments below for more information.
Status | New | ⇒ | Pending |
Category | ⇒ | Libraries |
Thought I will have a fight to remove it, so I took the easy way and wanted at least to add a proper message. I'm ok with removal too as it exists now for a couple of years in the J3 code base and it would be an acceptable BC break IMO.
Labels |
Added:
?
|
Category | Libraries | ⇒ | Libraries Front End Plugins |
Ok, removed the functions
Title |
|
Title |
|
Labels |
Added:
?
|
I have tested this item
I have tested this item
I have tested this item
Status | Pending | ⇒ | Ready to Commit |
RTC
RTC
We have a few isAdmin
in the vendor folder. Do these have to be taken care of?
Labels |
Added:
?
|
@infograf768 Where? I don't see them.
In a weird form
/libraries/vendor/codeception/codeception/docs/modules/Db.md
/libraries/vendor/codeception/codeception/docs/modules/MongoDb.md
It is also present, although commented out in 3 other files.
I have absolutely no idea what these files are for btw... and if isAdmin is used or not.
Codeception is not the Joomla API.
Just because an isAdmin
method exists does not mean it is working with an object that is a subclass of our CMSApplication
. Hint: anything in the libraries/vendor
directory isn't working in that context
Status | Ready to Commit | ⇒ | Fixed in Code Base |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2019-02-02 23:28:58 |
Closed_By | ⇒ | wilsonge |
Thanks!
By removing this code we completely kill sites on upgrade and leave them in a state that they cannot be recovered from
Can you elaborate? Presumably that’s if sites are running plugins with this code in?
It's enough to have an isSite/isAdmin in a system plugin to kill a website.
Unsure whether this is a good idea. We have a permanent 3rd application type (in the console App https://github.com/joomla/joomla-cms/blob/4.0-dev/libraries/src/Application/ConsoleApplication.php )
And the API app will be a type 4 when it gets introduced which will definitely be in the 4.x series (maybe 4.0 if i put the base app code in without the base extension classes)... So this method is going to behave differently in j4 to j3 :/
i.e. what i'm saying is because we have more application types maybe we should consider removing this in j4. unsure