I was able to test the patch and confirmed that if "Repeats on every" is set to 1 or higher, the setting is preserved in the node's edit form. However, when I click on Add to Calendar (any of the links), the "Repeat" value is not included and only the individual date I clicked on is added to the calendar.
It looks like the issue referenced above has been closed. Any updates on whether recurring events can be done with Calendar_link?
Thank you, @vladimiraus. I successfully tested changing settings options for fontawesome.
Yes, that was it. Thanks, @vladimiraus. I was able to install and enable the fontawesome module in Drupal 11. However, when I go to FontAwesome's settings page (admin/config/content/fontawesome), I get the following error:
ArgumentCountError: Too few arguments to function Drupal\Core\Form\ConfigFormBase::__construct(), 1 passed in /var/www/html/web/modules/contrib/fontawesome/src/Form/SettingsForm.php on line 30 and exactly 2 expected in Drupal\Core\Form\ConfigFormBase->__construct() (line 43 of core/lib/Drupal/Core/Form/ConfigFormBase.php).
Drupal\fontawesome\Form\SettingsForm->__construct() (Line: 39)
Drupal\fontawesome\Form\SettingsForm::create() (Line: 36)
Drupal\Core\DependencyInjection\ClassResolver->getInstanceFromDefinition() (Line: 48)
Drupal\Core\Controller\HtmlFormController->getFormObject() (Line: 58)
Drupal\Core\Controller\FormController->getContentResult()
call_user_func_array() (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 593)
Drupal\Core\Render\Renderer->executeInRenderContext() (Line: 121)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext() (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 183)
Symfony\Component\HttpKernel\HttpKernel->handleRaw() (Line: 76)
Symfony\Component\HttpKernel\HttpKernel->handle() (Line: 53)
Drupal\Core\StackMiddleware\Session->handle() (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->handle() (Line: 28)
Drupal\Core\StackMiddleware\ContentLength->handle() (Line: 32)
Drupal\big_pipe\StackMiddleware\ContentLength->handle() (Line: 106)
Drupal\page_cache\StackMiddleware\PageCache->pass() (Line: 85)
Drupal\page_cache\StackMiddleware\PageCache->handle() (Line: 48)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle() (Line: 51)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle() (Line: 36)
Drupal\Core\StackMiddleware\AjaxPageState->handle() (Line: 51)
Drupal\Core\StackMiddleware\StackedHttpKernel->handle() (Line: 709)
Drupal\Core\DrupalKernel->handle() (Line: 19)
Instruction in #4 did not work for me on a new vanilla Drupal 11 installation. I get the following error:
Your requirements could not be resolved to an installable set of packages.
Problem 1
- Root composer.json requires drupal/fontawesome dev-3465765-drupal-11-compatibility, it is satisfiable by drupal/fontawesome[dev-3465765-drupal-11-compatibility] from vcs repo (git https://git.drupalcode.org/issue/fontawesome-3465765.git) but drupal/fontawesome[dev-1.x, dev-2.x, 1.1.0, ..., 1.x-dev (alias of dev-1.x), 2.0.0-alpha1, ..., 2.x-dev (alias of dev-2.x)] from composer repo (https://packages.drupal.org/8) has higher repository priority. The packages from the higher priority repository do not match your constraint and are therefore not installable. That repository is canonical so the lower priority repo's packages are not installable. See https://getcomposer.org/repoprio for details and assistance.
I am experiencing the same issue when searching for icons, the icon images are not displaying. I thought the Fontawesome team had fixed this issue for Pro accounts. Any thoughts on what I can do to get search to work properly with Pro? Thanks.
I experienced the same issue and @juamerico's solution ( #5 π Cannot crop based on original image after initial crop has been set Active ), worked for me.
mariohernandez β created an issue.
I created a new issue for conditional_fields not working inside layout_paragraphs.
Hoping we get some solution to it.
https://www.drupal.org/project/conditional_fields/issues/3390509
π
Not working in layout_paragraphs
Active
This issue is also present in Drupal 10.2+
I appreciate your review, @ressa and I am happy you found the content useful. Maybe an update to the DDEV post would be more useful now that you mention it. Good luck with your responsive images and if there is anything I can do to help feel free to ping me in Drupal slack.
Thank you very much, @apaderno and @ressa. Not sure if you've noticed but two weeks ago I published 7 new articles all related to Drupal. I appreciate your assistance with my request.
p.s. Working on my next blog post which I am planning to publish sometime next month.
Hello @apaderno, Is the work that is needed to be done by me or someone else? I'm not clear on whether there is something on my end that needs to be done or not. Thanks.
Hello @apaderno, does you comment mean my blog has been added to Planet Drupal? I am expecting to publish a few blog posts this week. Thanks.
Great! Thank you. I actually have 7, yes 7, Drupal specific articles coming up. I am finishing up a blog series about responsive images in Drupal (a complete guide). Thanks for your prompt response.
Has anyone been able to create template suggestions for the directions link?
mariohernandez β created an issue.
slucero β credited mariohernandez β .
mariohernandez β created an issue.
After additional testing, I found that the provided patch for the "Controlled-by" field works as expected in paragraphs. The issue I am experiencing is probably caused by the fact that we are using Layout Paragraphs for adding paragraphs content rather than adding our paragraph types as an entity reference field within another entity (i.e. Content type).
I have applied several of the patches provided in this issue and I am still having the issue with the "Controlled by" field not working in a paragraph type. I am running the 4.0.0-alpha3 version of the module in a Drupal 9.5.11 and PHP 8.1 environment. How is it that the patch works for some people and not others? Thanks to everyone who has helped on trying to solve this issue, but I don't know what else I can do to make this work in a paragraph type. If anyone has any idea as to what the issue might be I'd appreciate your feedback. Thanks.
Closing after merging MR.
mariohernandez β made their first commit to this issueβs fork.
mariohernandez β made their first commit to this issueβs fork.
These items have already been fixed in the 3.0 beta 1 release
mariohernandez β made their first commit to this issueβs fork.
Added reference to a fixed bug.
Fix has been merged.
Please use MR #79 if you wish to test this fix.
Patch #3 worked on Drupal 10.1.0 with PHP 8.1.16.
+1 RTBC
Updated error message and steps to reproduce.
Adds example of error message.,
Added twig's docs reference.
Updated headings.
mariohernandez β created an issue.
Applied patch provided by the community to make simplify_menu Drupal 10 compatible.
Added fixed bug issue number to parent issue.
Closing issue after merging the bug fix.
mariohernandez β created an issue.
This bug has been fixed for D9 and D10.
Expanded on how Twig can be used when working with components or variables defined in YML.
mariohernandez β created an issue.
I reviewed and successfully tested the fixes in this MR on a new clean Drupal 10 site.