Love Fuel?    Donate

FuelPHP Forums

Ask your question about FuelPHP in the appropriate forum, or help others by answering their questions.
Browscap is closed.
  • The Browser Capabilities Project is closed. http://browsers.garykeith.com/stream.asp?BrowsCapINI
    It is used by 'Agent' class.
    What do I use instead?
  • That is bad news. I hope the project gets a restart. I'll have a look to see if we can include a version in the repo on the 1.4 release, so even not 100% up to date, you can still use the Agent class.
  • I just realised this was broken. Anyone know a good alternative?
  • 1.4 has an alternative implemented, so if you use that, it should work ok again.
  • Thanks. I just updated the config file and it's working again.
  • Is there an alternate source for BrowseCap? 

    The current one for http://tempdownloads.browserscap.com/ is not working as it says "Bandwidth Exceeded"

    Unfortunately Fuel 1.5.2 Doesnt fail gracefully and it shows an error when this happens.
  • Not that I know of, I've already looked.

    What do you mean by "not gracefully"? It writes an entry in the log file that it couldn't load the file, and continues?
  • Fortunately it's back up now.  I'll be keeping a local copy of this file now because it seems to be unreliable

    nearo - check display_errors is not on in your public/index.php file

    /**
    * Set error reporting and display errors settings. You will want to change these when in production.
    */
    error_reporting(-1);
    ini_set('display_errors', 1);
  • Thank you for pointing that out, I forgot about the location of the display_errors.

    Is it possible to move this to the config so it can perform similar to the dev/test/production environment changes?


  • Yes, that is no problem.

    But not really needed, as the error handlers will capture all errors, and they will not expose any error messages when running in production.
  • Thank you for the info. I think what I am going for is a way to have errors displayed on the dev / test environment, but not displayed in production, while having a single code base that changes based on the environment configuration.

    Does that make sense?

  • That is the standard concept of working, yes.
  • If Fuel can't get browsercap data, the cache will expire sometime and then we can't use Agent class at all. The current implementation is not fail safe.

    It is better that the cache never expires, isn't it?
  • It's best to download the browscap file manually and store it locally.

    Then either use that for Agent, and use cron to update your local file. Or capture the case that the download/update fails, and if so switch to your local backup. That will keep you up to date if the file exists, and will re-use the old one if not.

    If you extend or even disable expiry, it will take longer (or even never) to check for an update again.

    If you go this route, you can change the default expiry (set to 7 days) in your agent config file.
  • How about this?

    If it fails to download Browscap, use expired cache.

    https://github.com/kenjis/fuel-core/commit/cf1881dfdb48e264c543b0c82f57c656df903694
  • That still means that if there is a hickup when the cache just expired, you'll re-cache the expired cache for another week.

    I've come up with a better and more transparent solution, which I'll commit in a minute...

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

In this Discussion