Thank you !
Hi,
Sorry to barge in like that in an old thread, but the solution found here has not been implemented yet in DM 6.10. I had the same kind of need, and was able to do the same modification, so that ‘personnal’ documents could appear in category shortcodes.
Could you check if this modification is planned for the next version ? And while I’m at it, could it be incorporated too in wpdm-archive-page ? I tried, and if you put that same line of code in wpdm-archive-page > src > __ > __.php, around line 209, it also works great.
That would really be useful if this could be integrated, instead of us having to redo the modification after each update.
Thanks for your help !
Thanks, it’s done !
Excellent, thank you !
Thanks for your answer. Ideally, the values selected as default in the backend (in Downloads > Settings > Default Values) would be the default values for frontend upploader files.
Re-applying the default values everytime a document is created / updated seems like overdoing it.
Well, that much seems obvious, thanks.
The question is : what customisation, and why does a functionnality that was present before not work now ? I can refer you to the thread where I asked the same question (like, 2-3 years ago), and where frontend compatibility was part of the default value add on :
– see https://www.wpdownloadmanager.com/support/topic/page-template-and-default-values/
oh, and also see :
– https://www.wpdownloadmanager.com/support/topic/default-package-permissions-are-not-being-set/
– https://www.wpdownloadmanager.com/support/topic/wpdm-default-valuesdoesnt-work/
So there is very probably a solution to this. The question is, waht is it ? And why not integrate it to the add-on, considering the number of threads on the subject ?
Thanks for you help !
Hi,
Thanks for your answer. Another option (might be simpler, actually) is to just incorporate aria-label in the scripts.js, which is what I did to solve the problem (but is not upadte resistant). Here’s the changed code (starts at line 28) :
var html = "<ul class='pagination wpdm-pagination pagination-centered text-center'>";
console.log(current);
if(current > 1)
//added aria-label
html += "<li><a href='#' aria-label='page précédente' data-page='"+(current-1)+"' class='async_page page-numbers'><i style=\"display: inline-block;width: 8px;height: 8px;border-right: 1px solid;border-top: 1px solid;transform: rotate(-135deg);margin-left: -2px;margin-top: 2px;\"></i></a></li>"
for(i = 0; i < rangeWithDots.length; i++){
var cclass = parseInt(rangeWithDots[i]) === current ? 'current-page' : '';
//added new var to add current class to the aria-label
var ariaclass = parseInt(rangeWithDots[i]) === current ? ' - page courante' : '';
if(rangeWithDots[i] !== '...')
//added aria-label
html += "<li><a href='#' aria-label='Aller à la page "+rangeWithDots[i]+""+ariaclass+"' data-page='"+rangeWithDots[i]+"' class='async_page page-numbers "+cclass+"'>"+rangeWithDots[i]+"</a></li>";
else
//added aria-hidden
html += "<li><a aria-hidden='true' class='page-numbers dot'>"+rangeWithDots[i]+"</a></li>";
}
if(current < last)
//added aria-label
html += "<li><a href='#' aria-label='page suivante' data-page='"+(current+1)+"' class='async_page page-numbers'><i style=\"display: inline-block;width: 8px;height: 8px;border-right: 1px solid;border-top: 1px solid;transform: rotate(45deg);margin-left: -2px;margin-top: -2px;\"></i></a></li>"
html += "</ul>";
//added nav element
return "<div class='text-center'><nav aria-label='pagination'>"+html+"</nav></div>";
}
As you can see, it’s not that much work, and integrating these (preferably in multilingual fashion) would solve the problem once and for all…
Cheers, and thanks !
Thanks ! I did that yesterday, but didn’t get an answer yet. I figured it might be faster through the forums 🙂
Thanks ! I couldn’t find it.
Sadly, it appears there’s no hook or filter I could use to make the modifications… which would imply making modifications in the file itself, which I dislike for obvious reasons.
Basically, the website I’ve built has a registration approval system; to make sure of the visitor’s identity before confirming their account, some custom metadata is used (like phone number and such). It would save time if this metadata could be included in the email, which would be possible with the method you use to create it – you manage to get, for example, the first and last name of the user, which are supposedly metadata in wordpress and as such not available for a new registration email. (the custom metadata is part of the post data that can be extracted, since it is included in the registration form).
So achieving my objectives would, ideally, require custom placeholders (I’ve done it before for page / link templates, so I imagine it’s possible for emails) and a template… But hooks or filters might also do the trick (for email recipient and custom placeholders that are user-dependent). Is there any plan to integrate something like this in the future ?
Thanks again for your help, and for a great plugin and support !
Hello again,
Good news : I managed to achieve the desired result, thanks to this page :
https://wordpress.stackexchange.com/questions/290987/add-role-selector-to-custom-registration-page?rq=1
The only changes I had to make were to change the action to act on wpdm_register_form instead of register_form, and change the user role names in the array.
I will mark this thread as resolved.
Excellent ! Thank you !
May I know what was causing not to work ? (Just in case I need to avoid repeating whatever I did that made it not work…)
Ok, thanks !
Any idea when that might be coming 🙂 ?
Oh, and if I use [wpdm_frontend flaturl=0] but also uses custom templates for author-dashboard and wpdm-add-new-file-front, would default values stille work ? Because I just tried, and it stille doesn’t seem to work.
Thanks for all your help !
By the way, I am using the [wpdm_package_form] shortcode, if that makes a difference.
Hello again,
Apart from the easy update problem just above, I just updated the plugin the old fashioned way (deleting and then reinstalling, then resaving the options), so I have 4.7.8 and default values 1.7.0, and the default values still do not work in the front end…
Any idea ?
Cheers!
I have since the first day I installed the plugin, but I got the Special Pack, and I cannot find the base plugin in the list, for some reason (see attached screen capture…) And it doesn’t offer me the option to update on the wordpress plugin page either (maybe the update is recent ?)
Thanks for your help !
Well, my download manager version was 4.7.7, so I’m going to try that.
By the way, is there a friendly way to update ? I can’t seem to find any functionnality to that effect in the backend ; am I supposed to download the zip file every time, deactivate and delete the old version, and install the new one ? Seems not very user-friendly…
Thanks !