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 isClient($identifier) works with all supported versions and in the end a search and replace. :)

"break some things that is what we all should expect from a new major version"
no. This is only what you expect.

Given a version number MAJOR.MINOR.PATCH, increment the:
MAJOR version when you make incompatible API changes,
MINOR version when you add functionality in a backwards-compatible manner, and
PATCH version when you make backwards-compatible bug fixes.
Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.

https://semver.org/

no. This is only what you expect.

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:
https://docs.joomla.org/Release_and_support_cycle
https://developer.joomla.org/news/586-joomla-development-strategy.html#backward_compatibility

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.
I understand that a major version breaks things because we can not do differently, but here is an example of a useless decision. this does not affect the code in any way, just the look and feel of the ones that want to have a "new" code for the major version

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
Regards
CEd

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 cli client with 4.0 and we want to code to work the same in 3.x and 4.x

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 ;)

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.

Anyway thank you very much for pointing me the right direction for the function, I will replace it in my code

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 ;)

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

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 ?

In this example, just tell me what is the problem of having a isAdmin function in the code ?

isAdmin and isSite were written at a time where Joomla was only conceivably running its core administrator and site applications. They were never suitable for identifying the installation application, or a highly advanced use case such as the custom API application in the downloads site. 4.0 adds two new applications; API and Console (CLI). Those are neither site nor admin applications in the sense of what those methods are intended to describe, and the API could in some ways be both depending on the action. So, the appropriate action is to deprecate the two previously existing methods which by design only work for two specific applications and introduce a more flexible method which can work with the now 5 applications (site, admin, install, API, console) that exist, and be flexible enough for later growth or new use cases.

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 isAdmin(), which caused a blank white page, on site and on admin, with only the word Error printed at the top left corner. Both Site and admin were down for quite some time while someone had to pick over each file guess as which files were part of the template, and try delete anything related to the template, hit refresh page, until much nerve wracking and fingernail biting stressful time later, the site and admin finally came back to life with the default Cassiopeia template. There must be a better way to do API updates than this. At the very least, J4/PHP should NOT die/crash from accidentally calling to deprecated/outdated API methods. ?

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

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 error.php file.

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.
If we imagine that people will update from J3 to J4 and that they could find the website down without the knowledge of the reason, this is not funny. And we can't even think that for a site administrator it's easy to find a plugin that is calling isSite/isAdmin somewhere. Personally i would have avoid this risk.

is it not possible to alias isSite to isClient('Site')

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 isAdmin and isSite function ever since the deprecation was introduced.

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 isAdmin(), for example. The code would need to catch the bad method call and then show the logged in authenticated admin, on their browser, that a bad method call occurred, what file, what line. It looks like this is available within the PHP language, as described here:
https://www.php.net/manual/en/class.badmethodcallexception.php
and must be used with the __call magic method to work.

But sure, let's fuss about this minute issue.

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,
I even removed the templates and changed the database so that it would take the new ones and YET... on back-end:
0 Call to undefined method Joomla\CMS\Application\AdministratorApplication::isAdmin()
and on front-end numerous problems with different Joomla files, most of them seem to be Joomla files! Why doesn't the installer just re-upload them?

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 : /