🇺🇸United States @josh.fabean

volkswagenchick → credited josh.fabean → .

I also am getting this trying to upgrade to 10.3.10, for me downgrading doctrine/deprecations:1.1.3 isn't working.

Pulled Marco.aresu's patch #14 into the MR, then added

$form_state->getFormObject()->getEntity()->hasField('default_langcode')

To make sure default_langcode exists before trying to get it as that was throwing a PHP error for me on a registration entity on a site with only one language on it.

josh.fabean → made their first commit to this issue’s fork.

Added Drupal 11 support, updated usage, and last updated time.

Patch is applied in latest 2.2.x and will be 2.2.12, thanks!

josh.fabean → created an issue.

You have been removed.

This is live in 2.2.11.

Thanks, that's live in 2.2.11.

josh.fabean → created an issue.

volkswagenchick → credited josh.fabean → .

Created a MR, looks like Drupal isn't auto populating that it was created, not sure if that's just being slow or if there was a bug because I told it to fork from 5.1.x but it ended up forking off 5.0.x and I had to manually change things.

https://git.drupalcode.org/project/backup_migrate/-/merge_requests/40

josh.fabean → created an issue.

I think what you're actually seeing is the Bookable Calendar Opening page, but if you go back to the calendar you should see it. The url should be /bookable-calendar/ID.

This is merged and out in latest dev.

If you're wanting to capture the Address and Phone number of a person who is registering, adding it to the Booking Contact would be the correct place. What is the problem you're trying to solve by needing them in other places?

Thanks for finding this, luckily this is easy for you to fix on your end. All of those listing pages are Views and you can edit them and change the "Access" setting to be Permission based and set it to the "Access Booking Contact Overview Page" or whatever role or permission you want that's not viewable to everyone.

I pushed up new configs into dev, but those will not import for people who already have the module installed.

Tested and worked good, merged.

Also tested patch and removes the error for me.

I ran into this same issue, I looked at how other projects patched this issue for d10 and made the same changes. Here is one sample of another project patching the same issue: https://git.drupalcode.org/project/layout_builder_perms/-/merge_requests...

josh.fabean → made their first commit to this issue’s fork.

Removing the "only" from embed as in my experience that is not actually correct and if you do that slots won't actually render.

Pushed up a fixed to dev branch.

I can try creating the issue again. If you want to reach out to me on drupal slack and give me a database or something to better recreate the error, that could help.

josh.fabean → created an issue.

Good find, got that fixed and pushed to new version 2.2.9.

Can confirm I get the same exact error. That is strange, checking around integer is a valid base field definition that is used in Drupal Core.

Here is an example from core core/lib/Drupal/Core/Entity/ContentEntityBase.php

$fields[$entity_type->getKey('id')] = BaseFieldDefinition::create('integer')
        ->setLabel(new TranslatableMarkup('ID'))
        ->setReadOnly(TRUE)
        ->setSetting('unsigned', TRUE);

Here is how this module does it.

$fields['slots'] = BaseFieldDefinition::create('integer')
      ->setLabel(t('Slots'))
      ->setDescription(t("The number of available slots for this instance. If empty (NB not zero), will use calendar's defaults."))
      ->setCardinality(1)
      ->setDisplayOptions('form', [
        'type' => 'integer',
        'weight' => 10,
      ])
      ->setSetting('min', 0)
      ->setDisplayConfigurable('form', TRUE)
      ->setDisplayConfigurable('view', TRUE);

I see other drupal core issues that address having the same issue not sure I see a solution yet though. I'll look and see if I can find anything.

Tested that and everything seems to work as desired. Only change I made was change function _load_translated_entity to be namespaced to the module to not cause issues with other modules possibly.

In latest dev, will be in version 2.2.9 which should release today or tomorrow.

josh.fabean → made their first commit to this issue’s fork.

Thanks. I'm looking into that. I remember we created tokens, so things would work, didn't realize that breaks default entity tokens. Depending on if this changes or breaks existing tokens, might need to up version numbers or something.

Good find, got that fixed in latest dev. New version coming soon, trying to fix some more issues today first.

josh.fabean → created an issue.

Got that tested, latest version 2.2.8 requires smart_date 4+

Thanks, I'll test to make sure everything still works good with smart_date 4+ before making that change.

With changes to Calendar View this is no longer an issue.

Hi, with a little bit of a testing on the latest Calendar View module, I was able to recreate a display similar to what is in the module page.

In your View, you set it to show "Bookable Calendar Opening Instance" when creating the View then set format to be "Calendar by month", use fields and make sure to include the Date field.

I have attached in this issue a sample calendar View.

Got that added.

I added the context of "Claim a slot in this calendar" on the word "Book", and "This slot has already been claimed" for the word "Booked".

It's in latest dev, will get that in a full version shortly.

Got it, I was confused what Drupal Rector does vs phpcs. Getting this merged in.

Thank you for bringing this to my attention. Looked into it and there is no core way to flag a module as incompatible with another module. I updated documentation on the module page and the readme saying it's not compatible with BAT as we both created an entity called "Booking", I can probably fix this in the future but changing names of entities is a pretty big breaking changes so it would most likely have to be a 3x version of the module.

I've poked around with this and cannot recreate it. That is the default subject in the email that goes out to people when they claim a booking. On a fresh install with nothing else installed, I do not get that error. I then turned on the language module in Drupal since it's a translation issue, created a new booking and still no error.

I do see some changes that could be made around this email notification code but without being able to create the actual issue it's hard to know if they is still an issue.

Do you have more info on your site's setup that would help recreate this issue?

josh.fabean → created an issue.

I see this, I'll see if I can get something figured out here shortly.

After messing with this more, I was able to get it to work, but in a way that seems like I'm opening myself up to permissions issues by changing a permission check. In CertificateController:accessTab it returns the access checked of $entity->access('certificate', $requestedUser, TRUE);. The first param passed in is the operation you're checking against, but there is no "certificate" operation for nodes. I changed it to, $entity->access('view', $requestedUser, TRUE); as there is a view permission on nodes.

With this change, I still can only view my certificate if I'm logged in and have a Certificate Snapshot created for this use. If I go to view it logged in but a user who doesn't have an existing Certificate Snapshot I get a PHP error on trying to render it when nothing exists. For me this will the issue as I'm not displaying buttons to view cert if you don't have one generated, but I get this work around is not great as now it's trying to print it for everyone when they really shouldn't have one.

If someone has ideas, I'd gladly work on getting a better real patch working, but I did want to update this with steps in case others have a similar issue.

josh.fabean → created an issue.

josh.fabean → created an issue.

Thanks, Colan, that is added!

I just tested that documentation and was able to recreate the screenshot on the bottom by only copy and pasting the code samples, so it all works as it should.

josh.fabean → created an issue.

Thanks I'll look those over. I do personally have some confusion about what is proper for defining types in doc blocks as phpcs says give the full path but I'm pretty sure when you say --standard="Drupal" but when you say --standard="DrupalPractice" it says not to do that.

This is fixed in 2.2.6

This is merged in 2.2.6

josh.fabean → made their first commit to this issue’s fork.

Good find, I agree the word "book" instead great, I've struggled with what to call it even before you noticed it doesn't translate well. I can work on getting translation context added to all the parts in the module that need it.

Merged into dev, thanks for the find!

Just merged that all in.

Looks good, merged that to dev. We might need to come up with better verbiage on the buttons as there is no great indicator that clicking would cancel the booking, it currently shows the current state of the opening which makes sense but maybe it should change with one-click booking enabled.

josh.fabean → made their first commit to this issue’s fork.

Here is a pretty crude patch that just checks if the current theme is admin theme and if so just won't render the pattern using the same method that Views uses inside the Views preview.

I was thinking a better answer would be checking to confirm if template can be loaded, if it cannot output an error instead of white screening the website.

I'm having a similar issue, added ui_pattern display as a row display in a View, now I cannot edit my mega menu which uses a block from that view in it. I'm currently trying to figure if I can figure out a patch that checks to make sure template is available if not don't print or do something like Views does where it prints

Pattern Views row plugin does not support preview.

Thanks, I'll get this tested and merged in this week.

Thanks for working on this, just commenting to show support and I will gladly test this as we have client currently asking if this is a thing.

Was the intent to have something that gets up & running faster?

Hi, at one point I did have BEE listed as a similar module, I'm not opposed to adding that back in with some key differences.

This module was created when I had a couple clients at the same time needing some similar booking related features on their website. I originally tried going down the BEE/BAT route to see if those modules would fit my needs and they just seemed overly big and complicated for what I needed. The BEE module does require at least some parts from BAT to work, and BAT is aimed at Hotel booking type of flow. With the need to handle all the complexity that comes with that type of booking, I do understand why there is such a vast amount of settings to get up and running.

The intent of Bookable Calendar is to be a more simple repeating date booking system, I personally compare it more to the module Entity Registration → but if you have a repeating rule for your event that people register for. The examples I normally give are: Conference Rooms, Voice Lessons, Park Entry, Queue Reservation, or any place that is a repeating value like "every 15 minutes allow 5 people in".

Are there features over that this module has no plans to support (e.g. accepting payments)?

I'm sure there are some features that I don't think belong in this module, currently payments is not in my roadmap, but I'm not opposed to getting it to work with Commerce → and if people are wanting that I'm willing to push that up in the roadmap and do that before I do other features. The main hesitation I'd have about features would be adding features that add-in extra steps for the end user, as I want this to be easy enough for a non Drupal dev to be able to use.

How does the architecture differ?

As said before, BEE has a lot more settings, you can manage lots of different things that I seriously have no idea what they do. BEE attaches to existing Nodes (much like Entity Registration) where you edit a content type and turn on BEE for that node.

Bookable Calendar is a set of separate Content Entities, and you edit settings and everything for the calendars on those Entities instead of attaching them to Nodes. I personally think thanks to Smart Date → my repeat rule widget is way easier to use to make very complicated open/close rules.

Are there any other differences that users should know about?

Bookable Calendar is built to be a lightweight repeating date registration/booking module that pulls in as little amount of dependencies as it can and just use what Drupal already has to make things work in a simple enough way.

Thanks, I'm fine doing it that way if it's not something we want to get into the module. Thanks for the reply!

Did you try the suggested composer require 'drupal/bookable_calendar:^2.2' -W?

josh.fabean → created an issue.

When I first reached out to mandclu → a couple years about the Views integration issue he pointed me to this core issue 📌 [PP-1] Base fields miss out on Views data from hook_field_views_data() Postponed as a possible reason.

So as a workaround I copied the logic that was happening in smart_date.views.inc

So maybe the issue is that the date columns are different from what a field created in the GUI would be, so this code isn't working right. I'll see if I can match the database schema exactly of a date field created in the GUI and if it starts working.

josh.fabean → created an issue.

matthieuscarset → credited josh.fabean → .