Forum Replies Created

Viewing 10 replies - 1 through 10 (of 10 total)
  • Thread Starter spinfly

    (@spinfly)

    That query returns 2 BLOBs, so I changed the query to this:

    SELECT *, CONVERT(val USING utf8) from wp_wfconfig WHERE name="wp_site_url" OR name="wp_home_url";

    It indeed showed that https:// is saved for both values. Yet I am positive that some of my emails contained a link with https://

    • This reply was modified 5 years, 2 months ago by spinfly.
    Thread Starter spinfly

    (@spinfly)

    No, but is that really necessary?

    For all my sites, the WordPress Address (URL) and Site Address (URL) are correctly defined (with the correct protocols) on the WP settings pages:

    /wp-admin/options-general.php

    Thread Starter spinfly

    (@spinfly)

    FYI, this query on the DB will remove duplicates (rules defined first will be removed, rules defined later that are presumably more up-to-date will remain):

    DELETE
    n1
    FROM
    wp_redirection_items n1,
    wp_redirection_items n2
    WHERE
    n1.id < n2.id AND
    n1.url = n2.url

    Thread Starter spinfly

    (@spinfly)

    Whoops, this problem reared its ugly head again on one of our production sites…

    Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 72 bytes) in …/wp-content/plugins/php-browser-detection/lib/Browscap.php on line 573

    PHP 5.4.31
    WP 3.9.2
    PHP Browser Detection 3.1.1
    128 MB of memory on the server

    I have a theory that site traffic might cause this issue to flare up. The site on which this error occurred has had 654 sessions and 4165 pageviews since the it launched about two weeks ago.

    Thread Starter spinfly

    (@spinfly)

    On three different dev sites, after two weeks, everything seems fine. No more errors.

    Can we push this fix out with the next release? ??

    Thanks!

    Thread Starter spinfly

    (@spinfly)

    The initial install went fine, but I will have to wait a week or two before I know if there’s still an issue.

    Is there any way to force the issue?

    Thread Starter spinfly

    (@spinfly)

    But why is this NOT an issue when the plugin is first installed? And why does it suddenly become an issue after a few days or weeks? And why would deleting and reinstalling the plugin fix it?

    It’s not files themselves, as they don’t change from the point when the plugin is installed to the point that it fails. And I don’t think it’s the initial parse, because things indeed work fine when it is initially installed. Things only fail after a few days or weeks pass.

    I would guess that an increasing amount of information is stored to the DB until such a point that it’s too much for PHP to handle. And that deleting the plugin deletes the content from the DB and reinstalling the plugin allows it to start clean.

    In any case, if this is indeed a memory requirement of the plugin, is there any way to reduce it? Many shared hosting services have limited amount of memory:

    MediaTemple GS: 99MB limit
    BlueHost: 128MB limit
    HostGator: 256MB limit (nice!)
    DreamHost: 90M default
    GoDaddy: 64MB default
    RackSpace: 128MB default

    Thread Starter spinfly

    (@spinfly)

    Good idea, but in my case, I was already at 128M and still getting the errors.

    I do think it is indeed a memory issue. On another WP site I am developing (PHP 5.3.20 with 128 MB of memory, WordPress 3.9.1, PHP Browser Detection 3.0), I get the following message (this time, without the stream_socket_client warnings):

    Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 71 bytes) in /…/wp-content/plugins/php-browser-detection/lib/Browscap.php on line 864

    On each instance, when I delete the PHP Browser Detection plugin entirely and then reinstall and activate it, everything is fine. At least for a little while. Then, after a few days, the memory errors come back and the site dies.

    It looks like the memory errors seem to crop up in the section of code where the local browscap.ini file is parsed. I notice that the browscap.ini file that comes with the plugin (Version=5027, Released=Thu, 24 Apr 2014 07:41:24 +0000) is 10.4 MB, while a newer one that appeared on my server (Version=5029, Released=Thu, 08 May 2014 07:17:44 +0000) is 13.7 MB. Is it possible that PHP is choking when it tries to explode() and parse files that big? Perhaps it’s too much for PHP with 128 MB of memory to handle?

    Is there something else that’s being cached and growing over time that I am not seeing?

    Still seeing a weird memory issue on PHP Version 5.3.27.

    Is there some sort of memory leak or something with the plugin? Things are great when I first install it, then after a few days of use, I see the following error messages:

    Warning: stream_socket_client() [function.stream-socket-client]: unable to connect to https://browscap.org/version (Unable to find the socket transport “http” – did you forget to enable it when you configured PHP?) in /…/wp-content/plugins/php-browser-detection/lib/Browscap.php on line 1026

    Warning: stream_socket_client() [function.stream-socket-client]: unable to connect to https://browscap.org/stream?q=Full_PHP_BrowsCapINI (Unable to find the socket transport “http” – did you forget to enable it when you configured PHP?) in /…/wp-content/plugins/php-browser-detection/lib/Browscap.php on line 1026

    Fatal error: Allowed memory size of 103809024 bytes exhausted (tried to allocate 14701002 bytes) in /…/wp-content/plugins/php-browser-detection/lib/Browscap.php on line 875

    I’m on WordPress 3.9.1 with PHP Browser Detection 3.0.

Viewing 10 replies - 1 through 10 (of 10 total)