Thank you @samlerner.
By default, Drupal core's robots.txt already includes "Disallow: /search/" which requests search engines to not index the /search/ paths. Adding the robots meta tag may be redundant unless a search engine does not use the robots.txt or the site does not have Drupal's default robots.txt file.
But neither the robots.txt file nor the robots meta tag will prevent malicious bots from sending queries directly to the search application.
My thought is to add an option to check if the request to the search query came from the search form by passing a token. This would obviously "break" how the Drupal search currently works in that it does not require the request to come from the form so this request is an add-on that should be disabled by default, but I suspect most sites with the Vertex AI Search module would benefit, unless the site is already protected from bots.
As a quick fix, I was considering setting up my server to redirect any request to the /search path without the "searchPage" argument to the default search page. The "searchPage" argument appears to be added by the Vertex AI Search module to the search redirect URL. However, the "searchPage" argument is not added when submitting the search form from the Search Form Block, it's only added when submitting the search form from the search page. Of course, it's not a robust way to block bots, but all of the malicious bots hitting my search form are not going through the form itself, but rather sending the queries directly to the search URL (e.g. /search?keys=foobar).
christian deloach → created an issue.
This message means that the form (antibot_settings) has Antibot disabled - it is not being protected by Antibot. If you were to add "antibot_settings" to the Form IDs list, the message will change to "Antibot (antibot_settings): enabled" indicating that Antibot is enabled for the antibot_settings form. The message is displayed because you have the "Display form IDs" toggle enabled.
christian deloach → created an issue.
Thank you bkosborne for sharing this module. It works exactly as I need to prevent upscaling of images. I tried the Relative Crop and that did not work for me by itself. It's great for cropping by aspect ratio (e.g. 16:9) but does not scale the photo. I suppose the image could then be scaled using core's Scale effect but then I'd need a different module and I'd need two effects to achieve the same function as this module.
I guess it's a work in progress. The patch does restore the use of the
tag with and tags which appeared to be the primary focus of the issue, and is the ideal way to implement multiple image types, but does fall short of providing a responsive fallback image.
@John,
No, the img tag only contains a src attribute, no srcset attribute. While this means the fallback image is not responsive, the same can be said about the pre-patch markup which uses a srcset attribute for the .webp images and src attribute for the fallback .jpg image.
The ideal implementation would be to have a second tag with type="image/jpeg" rather than add responsiveness to the
fallback , for example:
Thank you Froozeify.
Your patched worked perfect! Images are now working correctly in Safari (MacOS Catalina).
Before your patch, images were rendered as John had reported:
<img srcset="xxxx.jpg.webp?itok=Xw9Xe3OC [...] src="xxxx.jpg.jpg?itok=LTjSBisl" [...]>
After applying the patch, images now render as:
<picture>
<source srcset="xxxx.jpg.webp?itok=Xw9Xe3OC [...] type="image/webp" sizes= [...]>
<img src="xxxx.jpg.jpg?itok=LTjSBisl [...] width="..." height="...">
</picture>Thanks endless_wander. Patch works great. Confirm that it addresses the issue with the missing accessCheck.
Thank you ptitb for this module. It works great!
My client has several location, and each location has their own set of ratings and reviews. It would be great to provide support for multiple Google Place ID's in the same block, combining the reviews and averaging out the rating.
I appreciate all of the time and effort addressing the fact that the description of the field does not currently match the current functionality.
I just started a new project that required visitors to get admin approval when creating an account and came across a potential side effect that may cause problems with changing how this email address is used. As the description states, this field serves two purposes. Not only is it used as the "from" address of the account-related emails, which we now know is actually behaving as the "reply-to" address, but it's also the "to" address of the emails that get sent for new user account approval notification emails. Ideally, there would be three separate addresses: the "from" address (would be something like no-reply@companyname.com), the "reply-to" address (would be something like info@companyname.com), and the "to" address for new user account approval notification emails (would be name-of-admin@companyname.com).
I agree with @larowlan's sentiment, changing this email address to be the "from" address may create unexpected problems for some, potentially reducing the delivery of there account-related emails as they may be flagged as spam. Our "from" addresses are typically no-reply@servername.com to help improve mail delivery and avoid having to go through a verification process for a client's email address (e.g. info@companyname.com). Having (keeping) the field as the "reply-to" address allows us to send emails from a no-reply@servername.com email address, but if a recipient were to reply, their email may go to a valid client email address. More importantly, it allows us to use a valid client email address as the "to" address of the new user account approval notification emails.
@leisurman,
It's been a while since I made this update, but going from memory, the Barrio Bootstrap 5 Theme → has a scheme file (config/schema/bootstrap_barrio.schema.yml) that was updated in the related issue referenced by @hatuhay ( https://www.drupal.org/project/bootstrap_barrio/issues/3333130 🐛 Missing schema definition for bootstrap_barrio_button_type Fixed ). However, because a subtheme may have its own scheme file, such is the case with Bootstrap Barrio's subtheme template and the Bootstrap 5 - SASS Starter Kit → subtheme, the subtheme's scheme file needs to be updated as well. The scheme file is in the config/schema directory of your subtheme. You will want to add the below to the section title "Button":
bootstrap_barrio_button_type:
type: string
label: 'Default button type'Christian DeLoach → created an issue.
@drupal-ramesh, be sure to apply both patches. There are two patches, one for Core and another for Rules. It looks like you may have installed the Rules patch only.
Ugh, I just realized the fix requires an update of the subtheme's scheme if using a Bootstrap 5 - SASS Starter Kit subtheme.
The related issue ( https://www.drupal.org/project/bootstrap_barrio/issues/3333130 🐛 Missing schema definition for bootstrap_barrio_button_type Fixed ) updates the Bootstrap Barrio's scheme file BUT a Bootstrap 5 - SASS Starter Kit subtheme has its own scheme file. Manually updating the subtheme's scheme file and resaving the subtheme's setting fixes the issue with the incomplete button class names.
hatuhay, I've installed the latest version (5.5.9) and continue to have this issue.
I've confirmed that the scheme was updated (from the related issue https://www.drupal.org/project/bootstrap_barrio/issues/3333130 🐛 Missing schema definition for bootstrap_barrio_button_type Fixed ).
I've gone to the theme's configuration page (Administration / Appearance / Appearance settings / Bootstrap Barrio), ensured that default button type was set to "Primary" (Components / Buttons / Default button type). I've even tried changing the setting to "Secondary" and while the change is saved and the correct value is displayed on subsequent redisplays of the theme's settings form, the bootstrap_barrio_button_type setting does not appear exist when theme_get_setting('bootstrap_barrio_button_type') is called by bootstrap_barrio_preprocess_input() (it keeps returning "null"). Any thoughts?
zaskia, the visually-hidden-focusable class is part of Bootstrap 5 (see https://getbootstrap.com/docs/5.0/helpers/visually-hidden/). Is it possible you aren't loading the entire Bootstrap CSS library or may be using a custom Bootstrap CSS library? Since the update provided by your patch was included in the latest release, why are we reopening this issue? Is there still an outstanding task?