How is it possible that someones browser does not declare the user agent? It is standard HTTP? I have not come across any whisper anywhere that this can happen. Do you know how this can be?

I realize the notice is not harmful indication of the plugin. And the plugin will run perfectly with the notice. As you know, the notice is for the developer to check existence of that variable.

I could turn off the notices, by turning off the debug mode in wp-config.php file.

define(‘WP_DEBUG’, false);

Or something like this could be applied in your user agent definitions PHP:

if(isset($_SERVER[‘HTTP_USER_AGENT’])) {
        //WordPress for iOS
        if ( stripos( $_SERVER[‘HTTP_USER_AGENT’], ‘wp-iphone’ ) !== false ) {
            return true;
        }
        //WordPress for Android
        elseif ( stripos( $_SERVER[‘HTTP_USER_AGENT’], ‘wp-android’ ) !== false ) {
            return true;
        }
        //WordPress for Windows Phone 7
        elseif ( stripos( $_SERVER[‘HTTP_USER_AGENT’], ‘wp-windowsphone’ ) !== false ) {
            return true;
        }
        //WordPress for Nokia
        elseif ( stripos( $_SERVER[‘HTTP_USER_AGENT’], ‘wp-nokia’ ) !== false ) {
            return true;
        }
        //WordPress for Blackberry
        elseif ( stripos( $_SERVER[‘HTTP_USER_AGENT’], ‘wp-blackberry’ ) !== false ) {
            return true;
        }
    }

Jetpack provides the whole list: https://github.com/xwp/wp-jetpack/blob/master/class.jetpack-user-agent.php

All of this may well soon be moot in any case as MS are starting to break from actually identifying the difference between a desktop and mobile device. However – the question still remains in what sort of browser is not identifying itself via the standards HTTP lays down. And that I don’t understand.

Yeah.. well, that’s beyond me I suppose I need to disable the debug mode then?

well, would be nice to understand, but debug mode is just that – meant for debugging… you shouldnt be running a production site with it enabled..

and confusing too what kind of browser you would be running that does not identify itself…

we do tend to make guard checks when applicable… but unlimited guard checks will affect performance…  there are normal/standard rules that are expected to be followed for some stuff…  and checks become extraneous… and in some cases may actually hide an issue you want to be flagged for research…

if we knew the use case for when the user agent string might be missing, we could perhaps understand and rationale some checks…

“confusing too what kind of browser you would be running that does not identify itself…”

The error log is on the server, not my computer. The errors are related to any number of browsers accessing the blog, not only one. Therefore my IE11 browser is not the issue. Is it is identifying 1000’s of users, resulting in the error.

Okay, better words would have been not sure what browsers “your users” would be running that don’t identify itself….

And as requested, if we could understand this use case, we might be able to better account for it…

The only report is the same line repeated 1,000’s of times:

Undefined index: HTTP_USER_AGENT in /problem-with-post-edit-buttonome/account/public_html/wp-content/plugins/simple-press/sp-api/sp-api-device.php on line 36

Since there is no way to perfectly identify the unknown anomaly, the next option would to make sure the HTTP exceptions listed all the primary browser types. Thus my suggesting looking at the github link, reviewing Jetpacks itemization compared to your own.

I looked at your predefined, $ua = $_SERVER[‘HTTP_USER_AGENT’] and noted a comprehensive list via Categorizr Version 1.1 which is two years out of date, and missing some of the prominent devices like Nokia.

What about appending a dumb_agents array?

var $dumb_agents = array(

  ‘nokia’, ‘blackberry’, ‘philips’, ‘samsung’, ‘sanyo’, ‘sony’, ‘panasonic’, ‘webos’,

  ‘ericsson’, ‘alcatel’, ‘palm’,

  ‘windows ce’, ‘opera mini’, ‘series60’, ‘series40’,

  ‘au-mic,’, ‘audiovox’, ‘avantgo’, ‘blazer’,

  ‘danger’, ‘docomo’, ‘epoc’,

  ‘ericy’, ‘i-mode’, ‘ipaq’,  ‘midp-‘,

  ‘mot-‘, ‘netfront’, ‘nitro’,

  ‘palmsource’,  ‘pocketpc’, ‘portalmmm’,

  ‘rover’, ‘sie-‘,

  ‘symbian’, ‘cldc-‘, ‘j2me’,

  ‘smartphone’, ‘up.browser’, ‘up.link’,

   ‘up.link’, ‘vodafone/’, ‘wap1.’, ‘wap2.’, ‘mobile’, ‘googlebot-mobile’,

 );

Whatever the case, the possibilities can be comprehensive, therefore I understand why a developer cannot include every possible device or agent.

There are a few points here. I number them simply for clarity…

1. We have no need to know that you may be using a Nokia. All we need to actually know is that you are using a mobile phone device. The current library performs that task just fine.
2. The issue of the standard ‘HTTP_USER_AGENT’ is the real and only important question. We have never encountered any device/access that does not pass this information. Indeed – I am surprised it is even legitimately getting through although I do wonder if it is not a user at all but some kind of bot crawling your site.
3. As Steve has already said – we could put a check in for an empty user agent string but the point is that we should not have to.
4. The current library that we use has indeed not been updated for a while – nor will it be and we have a development ticket open to deal with this at an appropriate time. The reason for this comes next!
5. Apparently – as I mentioned above – Microsoft in their continuing habit of throwing standards to the wind and going their own sweet way, have announced that they will no longer be differentiating the user agent they pass (I assume in IE but as I do not use any MS software I am not sure) meaning that all devices, from the smallest mobile phone to the largest desktop will all identify themselves as the same thing. This may or may not be limited to MS hardware – I am not sure on that point either. However, this throws ANY code library that attempts to identify the type of device being used into redundancy. Hence the lack of an update to the library. People are still trying to work out how to deal with this stupidity.