🇺🇸United States @josh.fabean

Created method to generate URL safe codes.

  protected static function generateUrlSafeCode(int $length): string {
    $chars = 'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789';
    $code = '';

    for ($i = 0; $i < $length; $i++) {
      $code .= $chars[random_int(0, strlen($chars) - 1)];
    }

    return $code;
  }

josh.fabean → created an issue.

Created new MR that moves from \Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher to \Symfony\Component\EventDispatcher\EventDispatcherInterface and it works as intended for me.

josh.fabean → created an issue.

With the latest update we had to make some permission type updates to fix a potential security issue so it makes sense this is something that could have broken. I can look at it and see how we can get it working again without opening back up that security issue.

poker10 → credited josh.fabean → .

I'm also stuck on this with the upgrade to facets 3.0.

volkswagenchick → credited josh.fabean → .

volkswagenchick → credited josh.fabean → .

Hi,

You are correct that it is currently a one way push from the repeating date field into individual instances.

Are you doing different location, price and things per individual instance, if not you could put that on the calendar or on the opening and pull it into the display with a relationship instead of filling each instance with duplicate information.

There is code to handle going to an individual opening instance, deleting it, and it deleting it from the parent opening but not adding, I'm also not sure how hard it would be to push dates into the date repeat rule either trying to do it that way.

The code where we handle adding an exception to the repeat rule on delete is here: https://git.drupalcode.org/project/bookable_calendar/-/blob/2.2.x/src/En...

I'm not sure the repeat rule would work but we could probably just have it add a one off date taking advantage of the multiple values that are allowed on the date field in the opening itself.

volkswagenchick → credited josh.fabean → .

volkswagenchick → credited josh.fabean → .

volkswagenchick → credited 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.