Is it possible to exclude a specific day of the week in date picker?
We have a scheduling system set up for our cleaning business, but we are closed on Sundays. We don’t want people to request pickups on that day or expect drop offs. How can that be blocked out?
@emmanuel would it make sense to add a javascript field in standard elements to be able to inject JS with extended options. I believe that you have a lot of elements were only a subset of options is provided.
This way the OP could use the date picker element and inject the following code to disable Sundays.
$(’.datepicker’).pickadate({
disable: [
1
]
})
Instead of having to create an element from scratch that is a duplicate of a standard one you provide.
It’s an interesting idea, but not sure it is wise to let people add code to some elements whose code isn’t public. We’re working on a forking feature though for plugins, which is in a similar spirit.
Actually I tried this just out of interest before you proposed, but when I didn’t get any results I assumed it was not possible this type of injection.
Now that I see your example I see that I’m probably using the wrong selector or the is something specific to this element that prevents this.
var $input=$('input.date_div.picker__input').pickadate();
var picker=$input.pickadate('picker');
picker.set("disable", [1,4,7]);
Emmanuel has a good point here. Although this is accessing a publicly shared API for the date picker, the selector is specific to the implementation, and could change on any Bubble update, breaking the workaround.
Use google chrome right click the element and inspect, should take you to the source highlighting the element, then you just work your way up the DOM tree until you find the element that actually represents the ‘thing’ that you can apply the customisation to.
There are sometimes other wrappers etc. that can get in the way, so the right click and inspect, just takes you to the general area in the DOM tree.
Related to providing an advanced feature to inject JS…this is actually doable with the HTML as not proven by me, but proven
It’s just to avoid cluttering html elements all over the pages which make it less user friendly.
If Bubble exposed the selector for the element through a variable it could always be referencing the right selector even with future changes.
Also in the information icon in the header, Bubble could add information about the plugin used(if used) and a link to the API/documentation if it exists.
And this could be considered like an advance/expert mode for elements that could be checked/unchecked in the APP settings. Even with a notice that there is no support out of the box for that part. So no tickets to help me with a custom js tweak. Only forum.
So basically it’s what we have right now with Custom HTML, but neat.
Man, I did not follow how to get from the picker to the end result, but I am excited to see there is progress with this.
Shouldn’t something like this be a standard option in the element settings anyway? I could imagine this being incredibly useful in many different situations.