silo

RE: ‘…folders can become corrupted or unstable’ — I agree. However, the issue, while intermittent, has also been consistent in popping up. This is the second or third time we’ve experienced this, and with different files.

This morning, I tested removing the the ‘hidden’ functionality, using straight ‘sdm_download’ in the shortcode (as opposed to the previous ‘sdm_hidden_download’), and using the old ‘7015’ id. This works correctly and as expected. Given that, it seems that the issue is stemming from somewhere within the workings of the ‘Hidden Downloads’ add-on.

We use our downloads as lead generators, so we’d like to keep direct links obfuscated. Again, if there is a way to resolve the issue (without having to stumble upon quiet failures, or have our users point out bad links, by re-adding the files), we’d like to help you troubleshoot it…

RE: debug, test page attempt — correct, yes; the initial debug test page download failed, again attempting to deliver the incorrect file.

RE: new download file attempt — added a new test file, updated the shortcode on the test page to the new test file ID, and tested download. Download was successful, delivering the correct test file. Log returned the following:

2024-06-13 14:22:07: Log has been reset. 2024-06-13 14:22:17: [SUCCESS] sdm_hd_process_download_action triggered. Download request is being processed by the hidden downloads addon.

…so removing/re-adding files works. FYI, we’ve successfully rebuilt, and re-added, downloads before, but would like to pinpoint the underlying issue if possible. As you know, intermittent problems—or at least what appear, at the moment, to be intermittent—are the worst! ??

EDIT: I should mention the obvious too, that re-adding downloads resets the download counts and in so doing throws off the statistics the clients likes to keep tabs on…

EDIT #2: RE: download counts — though, I’m seeing now that download counts can be adjusted with an offset…

• This reply was modified 9 months, 3 weeks ago by silo.
• This reply was modified 9 months, 3 weeks ago by silo.

Thank you for the response. After:

• enabling debug mode
• creating test page w/shortcode (id: 7015)
• testing download

…the log file returned a single line:

2024-06-12 17:08:33: [SUCCESS] sdm_hd_process_download_action triggered. Download request is being processed by the hidden downloads addon.

…I did reset the file and try once more. The returned lines were consistent:

2024-06-12 17:12:12: Log has been reset.——————————————————- 2024-06-12 17:12:26: [SUCCESS] sdm_hd_process_download_action triggered. Download request is being processed by the hidden downloads addon.

Tentatively, I think we have that fixed. Thank you for the help, the troubleshooting direction helped us. Turns out our simple ACF field was instead a post object, which of course required calling it slightly differently.

Ref: https://www.advancedcustomfields.com/resources/post-object/

I haven’t gotten a chance to work on this today, but thank you for this. What you sent looks like what we’re attempting, yes, but let me get wp_debug turned on and step through your screenshots just to make sure, and I’ll post back what I find.

@dnesscarkey — actually, I think I figured this out. This is on me. We’re using some critical CSS, generated earlier, at the top of the doc that didn’t get updated with the appropriate font-display: swap; rule. Sorry for the rabbit hole —?thank you for your time.

There is some confusing behavior here, however it does appear to work (at least on my install).

The issue is that there are two interfaces for changing order:

Products –> Categories (gives you small drag/drop handles to right of each term row)
Products –> Taxonomy Order –> Product categories (Categories)

Changing the FIRST will change output on the front end. Changing the SECOND will change output on the backend (the order of category options on a product edit page).

Custom Product Taxonomies
Even more confusing is that if you’re using a custom taxonomy that’s assigned to WooCommerce Products (‘Age’, for example), there is no drag/drop functionality on that taxonomy’s terms list page. There remains a single:

Products –> Taxonomy Order –> (‘Age’)

…option for changing order, but making changes here changes BOTH the front end and the backend in my testing. This can be confusing for your end-user. I’m guessing this is mostly a plugin UI inconsistency issue that they haven’t yet sorted out.

EDIT: Actually, this may be a bug. The two lists:

Products –> Categories (drag/drop)
Products –> Taxonomy Order –> Product categories (Categories)

…are tethered together, but only in one direction. Changes to SECOND will be reflected in the FIRST, but not the other way around. This may be an issue with the drag/drop functionality. In order to see changes on the front end, the drag/drop items must be dragged/dropped again, even if it’s away from and then back to the desired position. However, those changes don’t persist in the UI: refreshing the drag/drop page returns the items to the order reflected in Product –> Taxonomy Order –> Product categories (Categories).

• This reply was modified 6 years, 9 months ago by silo.
• This reply was modified 6 years, 9 months ago by silo.
• This reply was modified 6 years, 9 months ago by silo.

After you untick the author archive option, you might try nuking your browser cache. In my case, Firefox/Mac hung on to the redirect for some reason.