Forum Replies Created

Viewing 15 replies - 1 through 15 (of 47 total)
  • The developer’s solution (after using their ticketing system) is to direct you to download a fixed version of the plugin, only available via a uniquely generated off-site (not hosted by ww.wp.xz.cn) link

    So until they get around to fixing the version hosted on ww.wp.xz.cn

    You can suppress this error by replacing line 287 in /lib/exception/handler.php

    Replace this:
    return error_log( $message, 0 );

    With:
    return true;

    The developer’s solution (after using their ticketing system) is to direct you to download a fixed version of the plugin, only available via a uniquely generated off-site (not hosted by ww.wp.xz.cn) link

    So until they get around to fixing the version hosted on ww.wp.xz.cn

    You can suppress this error by replacing line 287 in /lib/exception/handler.php

    Replace this:
    return error_log( $message, 0 );

    With:
    return true;

    To fix this, change lines 103 and 104 of class.email-post-changes.php to read:

    $left = apply_filters( "wp_post_revision_field$field", $this->left_post->$field, $field, $this->left_post, 'from' );
    $right = apply_filters( "wp_post_revision_field$field", $this->right_post->$field, $field, $this->right_post, 'to' );

    The duplicate posts have become a real issue for me as well, starting around March 2020. I have noticed this happening specifically with iPhone Safari users.

    If they submit a form but don’t close the success page/tab, and then re-open safari at a later date– the browser sometimes initiate an HTTP POST that triggers the duplicate entry. This can be from a different IP address for example if they have moved from Wifi to cellular. This can happen hours or even days later from the original submission.

    More concerning is that this happens even when a form has the permission limit one post per user. In one case I used a form for a basic election/vote with the limit in place. The users were required to log in and vote. We had users voting multiple times completely unaware because of this issue. A re-attempt via a desktop browser will give the expected ‘you have already submitted this form’, but somehow Safari is getting around the check. You would think Formidable would re-query server-side to check the database for an existing submission by a user before accepting a duplicate post, but apparently it is not or somehow Safari is getting around it.

    I haven’t been able to pin it down but yet but it may be a somewhat recently introduced bug or has been recently exacerbated.

    sjlevy

    (@sjlevy)

    New update appears to have fixed the issue, thanks for that.

    I was having trouble reproducing it myself and was not in a position to grant access to the site, sorry I couldn’t provide more information.

    sjlevy

    (@sjlevy)

    I have a similar problem but different error, immediately after update:

    PHP Parse error: syntax error, unexpected 'private' (T_PRIVATE) in /var/www/wp-content/plugins/my-custom-css/pages/myphp/Edit.php on line 257

    I am having a similar problem with admin-ajax.php on a Multisite installation, directly after updating to 1.2.2, and I do not use WPML:

    [11-Mar-2019 18:41:58 UTC] PHP Fatal error: Uncaught Error: Class ‘InvisibleReCaptcha\Modules\WordPress\WordPressPublicModule’ not found in E:\inetpub\wwwroot\wp-content\plugins\invisible-recaptcha\engine\PublicEngine.php:30
    Stack trace:
    #0 E:\inetpub\wwwroot\wp-content\plugins\invisible-recaptcha\includes\plugin\MchBasePlugin.php(109): InvisibleReCaptcha\PublicEngine->__construct()
    #1 E:\inetpub\wwwroot\wp-content\plugins\invisible-recaptcha\engine\RequestHandler.php(24): InvisibleReCaptcha\MchLib\Plugin\MchBasePlugin::getInstance()
    #2 E:\inetpub\wwwroot\wp-includes\class-wp-hook.php(286): InvisibleReCaptcha\RequestHandler::InvisibleReCaptcha\{closure}(”)
    #3 E:\inetpub\wwwroot\wp-includes\class-wp-hook.php(310): WP_Hook->apply_filters(NULL, Array)
    #4 E:\inetpub\wwwroot\wp-includes\plugin.php(465): WP_Hook->do_action(Array)
    #5 E:\inetpub\wwwroot\wp-settings.php(374): do_action(‘plugins_loaded’)
    #6 E:\inetpub\wwwroot\wp-config.php(111): require_once(‘E:\\inetpub\\wwwr…’)
    #7 E:\inetpub\wwwroot\wp-load.php(37): require_once(‘E:\\inetpub\\wwwr…’)
    #8 E in E:\inetpub\wwwroot\wp-content\plugins\invisible-recaptcha\engine\PublicEngine.php on line 30

    Same issue here:

    PHP Fatal error: Class 'WPDM\admin\menus\Stats' not found in E:\inetpub\wwwroot\wp-content\plugins\download-manager\admin\class.WordPressDownloadManagerAdmin.php on line 13

    Reverted back to old version for now

    Thread Starter sjlevy

    (@sjlevy)

    After further inspection I still believe this to be a long filename issue

    The error was very repeatable with long post name entries

    I browsed to one of the paths, and attempted to write the same filename that comet-cache is.

    The filename was being truncated once the path hit 247 chars (windows path limitation is technically 260 but it wants allowance for 12 characters plus 1 null character, 247+12+1 = 260)

    From Microsoft: http://msdn.microsoft.com/en-us/library/aa365247(VS.85).aspx#maxpath

    Maximum Path Length Limitation

    In the Windows API (with some exceptions discussed in the following paragraphs), the maximum length for a path is MAX_PATH, which is defined as 260 characters. A local path is structured in the following order: drive letter, colon, backslash, name components separated by backslashes, and a terminating null character. For example, the maximum path on drive D is “D:\some 256-character path string<NUL>” where “<NUL>” represents the invisible terminating null character for the current system codepage. (The characters < > are used here for visual clarity and cannot be part of a valid path string.)

    By changing the character limit in the code cited by Raam I was able to resolve the issue. I altered lines 147 and 153 of Shared/CachePathUtils.php — down from 201 to a lower number.

    It appears that the length check in CachePathUtils is looking at the URL length instead of the filesystem path length, revising that code might resolve the issue for all Windows server users.

    • This reply was modified 8 years, 12 months ago by sjlevy.
    • This reply was modified 8 years, 12 months ago by bdbrown.
    Thread Starter sjlevy

    (@sjlevy)

    Ok thank you for the quick response

    Thread Starter sjlevy

    (@sjlevy)

    Raam,

    Thank you for being so responsive

    I apologize for not replying sooner, yes I probably made the wrong assumption. There could be something else locking the file.

    I will continue to investigate.

    Thread Starter sjlevy

    (@sjlevy)

    My apologies,

    It seems like wp-login.php always presents itself (even for logged in users)

    Thread Starter sjlevy

    (@sjlevy)

    Thanks for taking the time

    Sorry for the trouble

    Thread Starter sjlevy

    (@sjlevy)

    The developer points out that Windows/IIS is not supported which is understandable.

    The latest WP-SpamShield 1.9.8 update has removed all of the web.config’s introduced in 1.9.7.8 from the plugin directories. The plugin appears to be working correctly again on IIS (obviously minus the .htaccess restrictions)

    I had been trying to figure out why this 1.9.7.8 web.config directive would not work on my IIS configurations:

    <authorization>
        <allow users="*" />
    </authorization>

    Turns out it was because I needed to install the ‘URL Authorization’ feature, see the ‘Setup’ section of this doc: https://www.iis.net/configreference/system.webserver/security/authorization

    Additionally it looks like there were some syntax issues (at least with IIS version 8). IIS generates the authorization rule like this:

    <security>
        <authorization>
            <remove users="*" roles="" verbs="" />
            <add accessType="Allow" users="*" />
        </authorization>
    </security>

    Similarly a deny rule:

    <security>
        <authorization>
            <remove users="*" roles="" verbs="" />
            <add accessType="Deny" users="*" />
        </authorization>
    </security>

    The <remove> tag seems to be necessary to remove any inherited/default authorization.

    By replacing the 1.9.7.8 web.config directives with the new syntax above it was happy

    Thread Starter sjlevy

    (@sjlevy)

    Just a note to others having this issue

    I was able to remove or rename web.config in wp-content/plugins/wp-spamshield/js/, deactivate and reactivate the plugin to get an ‘installed correctly’ installation status

Viewing 15 replies - 1 through 15 (of 47 total)