Lastest update furbars links

  • 3.3.0 messed up downloading pdfs from links using this plugin. When I roll back to 3.2.4 the problem goes away. The pdf tries to load in but it never quite finishes it. Not sure on other file types since we use mostly pdfs.

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

  • Same here- had to roll back to 3.2.4.

    In my case, we mostly observed issues with Chromium-based browsers getting a ERR_HTTP2_PROTOCOL_ERROR.

    Plugin Contributor nwjames

    (@nwjames)

    @amontobin, @keithasmith
    I am sorry to hear that you are having problems.

    With little specific information, it is a bit difficult to identify the issue so I assume that it is in the serving of the file.

    This version does, by default, try to send the output to the browser in gzip form (but as a single file, i.e. not buffered).

    It is possible to switch it off and revert to use a simple readfile as previously.

    This is done by adding a php file to mu-plugins folder containing

    <?php
	add_filter( 'document_use_gzip', '__return_false' );

    I would be grateful to know any further information that you may be able to provide.

    Thanks in advance
    Neil James

    One more “I had the same issue”. Rolling back to 3.2.4 fixed.

    I hope this gets corrected soon.

    Plugin Contributor nwjames

    (@nwjames)

    All,
    Apologies, I wrote the filter name above as I originally wrote it. But before release I realised that the name could indicate that the document could be loaded into the server as compressed. So I changed it and the actual code to use is

    <?php
	add_filter( 'document_serve_use_gzip', '__return_false' );

    I would note that with gzip enabled, I do get a Content-Encoding: gzip header – and don’t get it with the above filter. This is as expected.

    As the comments referred to use of Chromium, and whilst I normally use FireFox, Edge has a Chromium engine, so I tried that. In normal use, the file loads successfully.

    I did try switching on the Developer tools to confirm what was happening. However on refresh, it gave the following response:
    <html><body><!-- no enabled plugin supports this MIME type --></body></html>

    I closed the Developer tools – and the document was displayed.

    It did give an error issue on the console:
    Response should include 'x-content-type-options' header.
    If anything, this should make it more likely to render.

    I then reverted the plug-in to version 3.2.4. No difference in behaviour was seen, with the pdf not loading with the developers tools on.

    A search for the error message would indicate a problem in the Content-Type header however since the code for this is identical between versions \I am at a loss to know what is the problem that you are experiencing.

    I would be grateful for any additional input that you may be able to provide.

    Neil James

    Plugin Author Ben Balter

    (@benbalter)

    Neil –

    Thanks, as always, for jumping in here. Given that it seems there’s some complexity/edge cases here, do you think it would make sense to make gzip handling opt-in rather than opt-out?

    gzip handling in PHP is admittedly new to me, but a brief search to try to educate myself suggests there may be some library dependencies and/or that gzip can be enabled via php.ini more reliably?

    All for keeping it in the plugin, but I’m wondering if we can reduce some potential errors for users depending on their setup/configuration, we can both reduce frustration and the need to support different environments.

    – Ben

    @benbalter,
    Gzip processing is actually opt-in. Why? Because it is only invoked because the browser says. via the HTTP_ACCEPT_ENCODING header that it accepts gzip.
    For most browsers – and certainly Chromium and FireFox, they output this header.

    The gzip pocessing is to simply call the standard PHP gzip processor. This also checks the browser capability.

    I don’t have an issue in switching it on explicitly. However, at the moment, we don’t know that it is the cause of the problem that these users have unfortunately experienced. Other than when I’m in debug mode with Chronium I have not found a problem.

    That was why I was hoping that someone that has the problem would implement the workaround and let us know if it resolves their issue. Then we will know that it is related to the gzip processing.

    Doing a release and not resolving the problem is frustrating.

    Let me know how you would like us to proceed.

    Regards,
    Neil

    Plugin Author Ben Balter

    (@benbalter)

    @nwjames fair point. I did some digging, and believe I have a theory, described in https://github.com/wp-document-revisions/wp-document-revisions/issues/254.

    If either of those fixes can resolve the issue (and are as simple as they appear to implement), that could potentially quickly resolve the issue without other users running into the same frustration.

    In the interim, please do give the filter fix a try and report back so we can confirm gzip is the culprit here.

    • This reply was modified 3 years, 4 months ago by Ben Balter.
    Plugin Author Ben Balter

    (@benbalter)

    For the folks on this thread that had trouble with 3.3.0, are you able to please confirm if 3.3.1 resolves the issue for you?

    As you’ve had no answers I can confirm that links are still borked in 3.3.1.

Viewing 9 replies - 1 through 9 (of 9 total)
  • The topic ‘Lastest update furbars links’ is closed to new replies.

Tags