The future of Joomla\Application\Client

[George Wilson]

Dear All,

Joomla\Application\Client is a weird beast. It's a browser detection library - but one that detects only the most common browsers and engines, also not using a good API (relying on getting all properties of the browser via Client::__get()). Generally this makes it pretty inflexible for use by people who want to use it in everyday scenarios. I'm sure we are all aware it's predecessor JBrowser (https://github.com/joomla/joomla-cms/blob/staging/libraries/joomla/environment/browser.php) in the CMS which was much more complete in browsers recognized but proved extremely hard to maintain.

To that end I started investigating moving away from Client and moving towards a 3rd party solution we could import with composer. The two most promising options I could find were https://github.com/gabrielbull/php-browser  and https://github.com/Ikimea/Browser. Whilst both solutions are acceptable in terms of browsers covered they do not cover the browser engine. This is important because we need an explicit check for the Trident engine in our own Joomla\Application\Web::redirect() method.

The alternative to a 3rd party solution is we expand our checks back towards how we found things in JBrowser with a more complete selection of browsers and move it into it's own standalone package that the Application package can import as a competitive solution to other products.

Does anyone have any thoughts or suggestions?

Kind Regards,

George

[Dmitry Rekun aka b2z]

Why not? But do you have any idea how to make it BC? Is Client will be just a adapter to 3rd party library?

Dmitry

[Sven Versteegen]

Does anyone have any thoughts or suggestions?

I would vote for the alternative solution you suggested (standalone package), because I would say that the Joomla community is much more active than any 3rd party solution and browser detection is a continuous job.

I did not check https://github.com/gabrielbull/php-browser but the https://github.com/Ikimea/Browser class looks like a solution based on the work from Gary White (http://www.apptools.com/phptools/browser) mentioned in this repo https://github.com/cbschuld/Browser.php which I would go for instead of the Ikimea repo if using a 3rd party one.

[dgt41]

One more option here: https://github.com/tobie/ua-parser

[Joe Palmer]

Another option is Which Browser that I've used in conjunction with the Joomla framework with great success:

https://github.com/WhichBrowser/WhichBrowser

On Sun, 31 May 2015 07:15 dgt41 <d.gram...@gmail.com> wrote:

One more option here: https://github.com/tobie/ua-parser

--
Framework source code: https://github.com/joomla-framework
Visit http://developer.joomla.org for more information about developing with Joomla!
---
You received this message because you are subscribed to the Google Groups "Joomla! Framework Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-frame...@googlegroups.com.
Visit this group at http://groups.google.com/group/joomla-dev-framework.

[Walt Sorensen]

I Agree, I was looking at this after helping to improve browser detection for a template framework. There is a lot that is not detected (edge for example), and somethings are attributed to the wrong rendering engine (chrome) because at some version the rendering engine in the browser changed. I had a hard time wrapping my head around the logic for how the WebClient browser detection worked or why it's setting the browser as a numeric constant. (basically I'm not sure how the consuming packages are using this library)

I think there is definitely interest in the WebClient browser detection being a separate package. 

There are also additional options for detection, currently we are using the $_SERVER['HTTP_USER_AGENT'] constant, and then using custom parsing of the user_agent string. We could possibly pull in the browscap.ini and use get_browser() to have a better object to work with. Although I'm not sure if pointing to a "custom" browscap.ini during runtime with ini_set('browscap', '[thebrowscap.ini file location]'); will give us the necessary ability to use get_browser()

The alternative would be pulling in a fully built out browscap library https://github.com/browscap/browscap-php (a userland replacement for PHP's native get_browser() function) 

[piotr_cz]

Piwik's Device detector package looks good and has only one dependency (YAML parser) and is actively updated.

App\WebClient browser detection seems to work for basic stuff - if you find some case scenarios, add a PR