Ruud Laan

Hi Razvan,

We found the issue. the Content-Disposition is set to ‘inline’ from a custom plugin which then messes up the whole filename thing and generates the error (perhaps catch this error?)

Now looking with the team for a solution on how to change this or not use XHR.

Thanks for your help

Hi Razvan,

>one inline JS constant was missing

Can you tell me which inline constant was missing or is it no longer missing now?

>why is the file name not being sent? Do you have any code in the htaccess that disallows the sending of file name header?

The .htaccess file just has the default WP stuff. But perhaps WP Engine does some stuff with their nginx setup. Can you tell me which header is supposed to exist with the filename?

Thanks

I did some further testing and replaced the dlm-xhr.js file with the 4.7.71 version. (with SCRIPT_DEBUG=1) and that worked. The download works as expected. I since replaced it again with the new version to allow further testing.

Thanks,
Ruud

Hi Razvan,

This staging site is on the WP Engine platform; Page caching is a standard feature and is always on. We can request cache exclusions. Caching might be related but the problem lies when logged in, which in normal circumstances already excludes caching.

This is the result for when I try the download when logged in =>

accept-ranges: bytes
cache-control: max-age=600, must-revalidate
content-description: File Transfer
content-disposition: inline
content-length: 129305
content-transfer-encoding: binary
content-type: application/pdf
date: Wed, 11 Jan 2023 13:22:18 GMT
dlm-download-id: 5926
dlm-version-id: 5929
expires: Wed, 11 Jan 1984 05:00:00 GMT
pragma: no-cache
server: nginx
vary: Accept-Encoding,Cookie
x-cache: MISS
x-cache-group: normal
x-cacheable: SHORT
x-orig-cache-control: no-cache, must-revalidate, max-age=0
x-powered-by: WP Engine
x-robots-tag: noindex, nofollow

When attempting this multiple times I get the same response headers. The PDF file itself is being downloaded and visible in the response data, but after reaching 100% nothing happens.

I retested the not logged in version and it also now seems to no longer work getting the same results. So could you please try and test on the test page to see what results you get? => https://caninecondistg.wpengine.com/test-dlm/

Hi Razvan,

We set up a test page: https://caninecondistg.wpengine.com/test-dlm/

In an incognito browser both links work normally on version 4.7.72, the unrestricted version opens de PDF, the RCP restricted version shows the restriction notification page.

When logged-in, both buttons upon click start getting a spinner, count to 100% and then nothing.

When downgrading to 4.7.71 it starts working again.

I upgraded again to 4.7.72 for you to test, but unsure if this description can help you.

Thanks,
Ruud

I see. Need to set up a version where we can test some stuff then.

Our setup also uses RCP with the RCP/DLM addon

Will get back to you tomorrow with a link.

Thanks!

Hi Razvan,

Thanks for your fast reply. It is a membership site. Let me work on this and get you a test account. How can I send credentials to you?

• This reply was modified 1 year, 10 months ago by Ruud Laan.

Hi f3l1x and StyleMix author

If you want this fixed in the plugin code itself, have a look at line 16 in hb_templates/main.php

The database option is not retrieve correct, and the line should be:

<script type="text/javascript">
        var stm_sticky = '<?php echo esc_js( stm_hb_get_option( 'header_sticky', '', $hb ) ); ?>';
    </script>

One other optimization could be that if no sticky is selected (value becomes empty) to check for that:

$stm_sticky = esc_js( stm_hb_get_option( 'header_sticky', '', $hb ) );

if ( ! empty ( $stm_sticky ) ) {
	echo sprintf( '<script type="text/javascript">var stm_sticky = \'%s\';</script>', $stm_sticky );
}

Thanks,
Ruud

Hi Travis, thanks!

Hi Patrick,

The cron is probably doing its job, but as you also found out, I’m guessing the part where the code is determining which records to delete is not working as it should.

” because no entries were found matching the search criteria.”

Is your expiration interval bases on hours, or days?

Thanks,
Ruud

Hi Patrick,

We are experiencing similar problems with the 2.0.1 version of the plugin.
Expiration is set on a per form basis (expire after 2 hours, check every hour) but entries do not get removed.

Have you had any luck in getting this working?

Thanks,
Ruud

Hi Sedelstein,

I can provide you with some answers on your questions:

1) The plugin developer merged my code enhancements into his plugin (‘master’) version. So you now can install this plugin (download here: https://github.com/kylephillips/favorites/archive/master.zip) and tweak the expiration time to your liking, with a filter (see: https://pippinsplugins.com/a-quick-introduction-to-using-filters/).
This also means you can make it very, very long as to be ‘non-expiring’ in real life ??

2) Any plugin is a potential risk, especialle if not being maintained. How much of a risk depends on your situation. However at the moment no security issues are known for this plugin, see: https://wpvulndb.com/plugins?get=F
I can also advice you to get on the wpvulndb mailinglist to keep receiving up-to-date plugin security notifications and then keep a look-out on this plugin. Once a security problem is found, disable the plugin, and wait to see if the developer is making a fix (or not).
If no security bugs show up, things are most likely all good (or at least not known by a lot of people)

3) I’m currently not aware of any other plugins with the same functionality. But with 40.000 plugins out there, there must be ??

Thanks,
Ruud

Hi Kyle,

Please have a look at: https://github.com/kylephillips/favorites/pull/52

By checking out your github version I found out that the WordPress SVN version uses a cookie expiration interval of only 3600 seconds, while your master branch on GitHub uses 1 year in seconds.

The timezone stuff doesn’t matter after all: the cookie time is set in GMT and checked accordingly, so no problems there.

Thanks,
Ruud

Hi Kyle,
I hope you can make some time to check this out.

Meanwhile I’m going to do some testing on the presumption that the favorites don’t work for people in a timezone more the +1 hours difference to the server time.

Keep you posted

Thanks,
Ruud

Thanks! much appreciated