-
-
Notifications
You must be signed in to change notification settings - Fork 3.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[4.0] Error: Call to undefined method Joomla\CMS\Application\AdministratorApplication::isAdmin() #24642
Comments
This method has been removed in 4.0. The extension is not compatible with 4.0. |
Closed as expected Behaviour. |
The new method (that can also be used in 3.x) would be: isClient('administrator') and isClient('site') :) |
lol, wouah what a super backward compatibility ! do you think that it helps in some way to remove such functions ? really ? |
Well 4.0 is about to break some things that is what we all should expect from a new major version. The mention method has been deprecated in October 2016 0fdd1ba So at some time old functions need to be removed ;) But the good thing is that |
"break some things that is what we all should expect from a new major version" |
Well as cited above this is the standard we (and many other projects) use for versions. And per that definition major's are the place to do incompatible API changes. Some more details can be found here: |
I know that. In this example, just tell me what is the problem of having a isAdmin function in the code ? this is a shortcut and I don't see what is exactly good in removing this function. Of course this appplies to other functions as well. Just my 2 cents, because backward compatibility must be a priority and I see that years after the bad experience from 2.5 to 3, we are still in the same way of breaking things. This is a shame Coding with "isAdmin" is much shorter (less code to write) and much understandable than "isClient('administrator') ". I'm just surprised that you don't see that, but of course I'm writing here for nothing because nothing will change ;) Anyway thank you very much for pointing me the right direction for the function, I will replace it in my code |
Well to me isClient is much more flexibel and also allow new things like $app->isClient('installation'); Details can be found here: #8971 & #22492 part of the reasoning was also because we have a new
Well feel free to propose a PR that adds that feature back when it is that critical. I can only explain the reasoning we had to remove that method in 4.x.
No problem. More changed things (not complete) are listed here: https://docs.joomla.org/Potential_backward_compatibility_issues_in_Joomla_4/en when you need them ;)
That is part of the reason 3.10 will still be supported after the 4.0 release and also why we backported as much as possible to 3.x so you can have one version of the extension running on 3.10 and 4.x 👍 |
|
Ran into this site crash bug today. It was caused by uploading a template believed to be compatible with J4. Alas the template was crafted for J3 and contained the unholy call to |
a blank white page is always a php error message in disguise. If you had enabled php error reporting either at the server level or in global configuration then the error would have been revealed |
Right, but can't we do better than letting php bomb in such a user-unfriendly admin-unfriendly and developer-unfriendly way. Can't J4 be made to be smart enough to do, either: 1. "Component installed. Deprecated API call detected. Uninstalling, reverting." and stay alive, or, 2. at the very least, when the user is on the admin, and is logged into the admin, print the call stack of the crash, or leta php package such as https://packagist.org/packages/filp/whoops print the stack. The admin having the stack right away during site-down emergencies, whether error reporting is enabled or not, would make manually recovering from them when seconds count much faster. |
The core templates should print the stack trace so long as error reporting is enabled and debug mode is enabled. This can also be done with your template’s Realistically, you should only WSOD if your error template (or something used by it, as 4.0 can “properly” support modules in error templates) triggers an error and error reporting is turned off. There is also good reason why all the “useful” info is disabled by default, way too many information disclosures are made if you default to error templates spitting out details that only a developer should see. Note there is also a higher level exception handler outside the application classes in Symfony’s Debug component, but with the design of the application and core exception handler that effectively will only get triggered on a startup error; once the application starts running all error handling is effectively within the Joomla API. |
Honestly i don't agree with the removal of isSite and isAdmin in this breaking way. It seems the most frequent reason why a PHP fatal error is triggered when installing an extension running on Joomla 3. Even worse, if the isSite/isAdmin is located in system plugin, like it's often out there, the entire website will be down, both frontend and backend. |
is it not possible to alias isSite to isClient('Site') |
@brianteeman Yes that would have been the way to go |
Create a pull request and then it can be tested ;) |
That is exactly how Short of Monopoly Matt™ and WordPress' approach of never removing deprecated elements (seriously there are things tagged as deprecated from a 0.x version), then removing something that is properly deprecated is going to cause someone pain somewhere along the way. There's no getting around it. Trust me, there are more flaws in J4 than the removal of these two methods from the application class chain. But sure, let's fuss about this minute issue. |
If you really think it's best to leave the deprecated methods out of 4.0, and I can see why you would, then at the very least, it'd be great if J4 could do something more helpful than WSOD when a deprecated removed method gets called, such as when a J3 component system plugin calls |
As it completely kills a site on update it is not a minute issue |
OK so upgrading 3.10.2 to 4.0.3, turned off the extensions that were shown as problems for the installer, |
In configuration.php set public $debug = true This will produce a stack trace so you can see which extension is causing the problem. You may be able to fix that extension yourself see https://youtu.be/ZO9nmdsLlFw |
Yeah, I think I have but then there were more errors : / including something that was supposed to be resolved in beta : / |
Steps to reproduce the issue
Install an extension and got the message
Error: Call to undefined method Joomla\CMS\Application\AdministratorApplication::isAdmin()
Expected result
No error
Actual result
System information (as much as possible)
Joomla 4 Alpha 9
Additional comments
Extension that works without problem on joomla 3.9
isAdmin() if a function that is used since years from the core. I don't understand why I got this problem
The text was updated successfully, but these errors were encountered: