And as I was investigating this prior to starting to module and core updates, I run those, and now I get even more entity mismatch issues with these:
Taxonomy term
The Publish state field needs to be installed.
The Unpublish state field needs to be installed.
I did run the core database updates, and they finished without any issues, so I'm just a bit confused why these are showing up.
I'm looking at this " Mismatched entity and/or field definitions → " module, but it seems like that just provides a UI for the drush command that this module provides. So again, it's just confusing what site maintainers are supposed to do about these warnings.
Reading my entity warning more carefully:
File type field
It's pointing to the field that the file entity module adds to the managed_file table. Did some more research, and it looks to be related to #3056070: Mismatched entity and/or field definitions updating from 8.6 to 8.7 → . Yes, this is an older site that was originally built in D8 using file_entity. I had a ticket to handle the migration at one point, but looking back, it seems that was closed in error.
bburg → created an issue.
@sonfd
Ultimately, while my steps appeared to work in the dev environment, it didn't in production. I ended up getting Pantheon support to rebuild the solr server on the back-end for me. Updating to the latest release of the Search API Pantheon → module should be the fix now as I understand.
So immediately after posting my last comment, I saw that there was a new 2.3.1 release, and a release note to re-run the update hook → . I did so, and it seems to be working now with the patch.
I have a view, which isn't returning any results, and seems like it is matching the issue described here as I have two relationships (Group, and Group content user). However, I do not get a resolution with the patch. When logged in as a user, on the page with the view, (/admin/group here), I don't get any results, when logged in as an admin, and in the view editor, if I add the user ID as the contextual filter argument, I do get results. The only filter I have is "Group relationship: Group relationship type". This did previously work in Group 2.2, but breaks on upgrading to 2.3.
I also tried dropping an xdebug breakpoint on the lines the patch added, and I don't see stopping on those lines at all. I haven't narrowed down if the view is actually getting results out of the query, or if they are being stripped some other way. That's a task for the morning.
Updated patch to work with 2.0.0
So patch in #3 does not actually fix the issue. I may have inadvertently replaced the original csv I was testing with.
So after some investigation, I think this is all that's really needed is adding this in MigrateSourceUiForm::submitForm(): to pass the updated configuration with a reference to the new file while instantiating the migration instance instead of the passing the config to MigrateBatchExecutable
$migration = $this->pluginManagerMigration->createInstance($migration_id, $options['configuration']);
Patch attached. Full disclosure, this was developed with assistance from ChatGPT.
Steps to fix the index via drush, with a Pantheon focus.
1. Get the list of the servers to get IDs
drush search-api:server-list
2. Run these commands to clear the Search schema schema from the API.
drush sapi-sd SERVER_ID
drush sapi-se SERVER_ID
drush solr-reload SERVER_IDNote: the search_api_pantheon_admin module must be enabled for this command
drush search-api:clear
drush search-api-pantheon:force-cleanup SERVER_ID
Note: Use server ID in step 1
3. Repost schema and re-enable the server
drush search-api-pantheon:postSchema SERVER_ID
drush sapi-ena SERVER_ID
4. Queue all content for re-indexing.
drush search-api:reset-tracker
5. Run the reindex.
drush search-api:index
Credit goes completely to mattdanger →
I was just looking into this issue and found that this is a duplicate to 🐛 Error: Attempt to assign property on array in WebformLibrariesCommands->setComposerLibraries() Active .
I updated the example in my previous comment to use a version starting from composer create-project per the documentation in
https://www.drupal.org/docs/develop/using-composer/manage-dependencies →
instead of my own starter version.
I still get the error as before.
This one has more boilerplate than it probably needs, but I do get the error. Just run site install, enable webform. and run the drush webform-composer-update command.
{
"name": "forumone/drupal-project",
"description": "Project template for Drupal projects with composer.",
"type": "project",
"license": "GPL-2.0-or-later",
"repositories": [
{
"type": "composer",
"url": "https://packages.drupal.org/8"
},
{
"type": "composer",
"url": "https://asset-packagist.org"
}
],
"require": {
"composer/installers": "^1.10",
"cweagans/composer-patches": "^1.7",
"drupal/core-composer-scaffold": "^10",
"drupal/core-recommended": "^10",
"drupal/core-vendor-hardening": "^10",
"drupal/libraries": "^4.0",
"drupal/webform": "^6.2",
"drush/drush": "^13.2",
"joachim-n/composer-manifest": "^1",
"npm-asset/select2": "^4.0",
"oomphinc/composer-installers-extender": "^2.0",
"rvtraveller/qs-composer-installer": ">=1.1",
"vlucas/phpdotenv": "^4.0",
"webmozart/path-util": ">=2.3"
},
"require-dev": {
"dealerdirect/phpcodesniffer-composer-installer": "^1.0",
"drupal/coder": "^8.3",
"mglaman/phpstan-drupal": "^1.1",
"phpspec/prophecy-phpunit": "^2",
"phpstan/extension-installer": "^1.2",
"phpstan/phpstan": "^1.9",
"phpstan/phpstan-deprecation-rules": "^1.0",
"squizlabs/php_codesniffer": "^3.7"
},
"conflict": {
"drupal/drupal": "*"
},
"minimum-stability": "dev",
"prefer-stable": true,
"config": {
"sort-packages": true,
"platform": {
"ext-gd": "1.0.0",
"ext-opcache": "1.0.0",
"ext-pdo": "1.0.0"
},
"allow-plugins": {
"cweagans/composer-patches": true,
"composer/installers": true,
"drupal/core-composer-scaffold": true,
"drupal/core-vendor-hardening": true,
"drupal/console-extend-plugin": true,
"dealerdirect/phpcodesniffer-composer-installer": true,
"joachim-n/composer-manifest": true,
"phpstan/extension-installer": true,
"rvtraveller/qs-composer-installer": true,
"oomphinc/composer-installers-extender": true
}
},
"autoload": {
"classmap": [
"scripts/composer/ScriptHandler.php"
],
"files": [
"load.environment.php"
]
},
"scripts": {
"install-codestandards": [
"PHPCSStandards\\Composer\\Plugin\\Installers\\PHPCodeSniffer\\Plugin::run"
],
"php-stan": [
"./vendor/bin/phpstan --memory-limit=1024M"
],
"phpcs": [
"./vendor/bin/phpcs"
],
"phpcbf": [
"./vendor/bin/phpcbf"
],
"build-assets": [
"composer install --optimize-autoloader --no-dev"
],
"lint": "find web/modules/custom web/themes/custom -name '*.php' -exec php -l {} \\;",
"code-sniff": [
"./vendor/bin/phpcs --standard=Drupal --extensions=php,module,inc,install,test,profile,theme,css,info,txt,md --ignore=node_modules,bower_components,vendor ./web/modules/custom",
"./vendor/bin/phpcs --standard=Drupal --extensions=php,module,inc,install,test,profile,theme,css,info,txt,md --ignore=node_modules,bower_components,vendor ./web/themes/custom",
"./vendor/bin/phpcs --standard=DrupalPractice --extensions=php,module,inc,install,test,profile,theme,css,info,txt,md --ignore=node_modules,bower_components,vendor ./web/modules/custom",
"./vendor/bin/phpcs --standard=DrupalPractice --extensions=php,module,inc,install,test,profile,theme,css,info,txt,md --ignore=node_modules,bower_components,vendor ./web/themes/custom"
],
"unit-test": "echo 'No unit test step defined.'",
"pre-install-cmd": [
"DrupalProject\\composer\\ScriptHandler::checkComposerVersion"
],
"pre-update-cmd": [
"DrupalProject\\composer\\ScriptHandler::checkComposerVersion"
],
"post-install-cmd": [
"DrupalProject\\composer\\ScriptHandler::createRequiredFiles",
"@install-codestandards"
],
"post-update-cmd": [
"DrupalProject\\composer\\ScriptHandler::createRequiredFiles"
],
"post-create-project-cmd": [
"DrupalProject\\composer\\ScriptHandler::createRequiredFiles"
]
},
"extra": {
"composer-exit-on-patch-failure": true,
"patches-file": "composer.patches.json",
"patchLevel": {
"drupal/core": "-p2"
},
"drupal-scaffold": {
"file-mapping": {
"[web-root]/CHANGELOG.txt": false,
"[web-root]/COPYRIGHT.txt": false,
"[web-root]/INSTALL.mysql.txt": false,
"[web-root]/INSTALL.pgsql.txt": false,
"[web-root]/INSTALL.sqlite.txt": false,
"[web-root]/INSTALL.txt": false,
"[web-root]/LICENSE.txt": false,
"[web-root]/MAINTAINERS.txt": false,
"[web-root]/README.md": false,
"[web-root]/UPDATE.txt": false,
"[web-root]/USAGE.txt": false
},
"locations": {
"web-root": "web/"
}
},
"installer-paths": {
"web/core": [
"type:drupal-core"
],
"web/libraries/{$name}": [
"type:drupal-library",
"type:bower-asset",
"type:npm-asset"
],
"web/modules/contrib/{$name}": [
"type:drupal-module"
],
"web/profiles/contrib/{$name}": [
"type:drupal-profile"
],
"web/themes/contrib/{$name}": [
"type:drupal-theme"
],
"drush/Commands/contrib/{$name}": [
"type:drupal-drush"
]
},
"installer-types": [
"bower-asset",
"npm-asset"
]
}
}
The error I get in patch from #6 is:
In RegisterEventSubscribersPass.php line 33:
Service "domain_path.subscriber" must implement interface "Symfony\Component\EventDispatcher\EventSubscriberInterface".
Seems like this was intended to be a part of the patch, but was excluded somehow.
It seem's that Magnific targets an element lower on the tree than Flybox is. FlyBox target's the anchor tag immediately below ".slide__media" elements. While Magnific Popup is targeting the parent ".splide" element. That might be somewhat on me, because I added a style that set's a max width, and uses "margin: 0 auto;" to center that.
I thought it might because I had the margins to overlap the buttons, but I moved that to the parent element, and I get the same result. So somehow a click event on the buttons propagates to the individual image element. In any case, I don't think that event listener is supposed to be on the ".splide" element.
The Fix in #5 worked for me. I was rendering the entire {{ rows }} variable in my custom view twig template, and switching to rendering {{ row.attributes }} and {{ row.content }} resolved it for me. It's explained in this Stack Overflow post.
Still not sure why upgrading to 10.3 triggers the appearance of this error though.
I'm also seeing this happen in 8.x-2.11.
Looking more at the patch, It's also adding another dependency to Smart Date via this "SmartDateTrait". Which we should only be optionally supporting if the site already has Smart Date installed, has configured an entity to use Smart Date fields, and then configured the ical view to use those fields. It shouldn't be declared as a trait to one of our classes like this, and I'm not really sure why it's even needed at all here.
As an aside, I get the impression that this patch was put together in an effort to farm contribution credit, and that the author(s) didn't have a local environment running, or make any attempt to test the patch in such an environment. If I see such posts in my module queue again, I will mark them as spam. If you use this module in your own projects, and are genuinely interested in contributing to it, then I am grateful for any effort there, but blindly posting untested patches just adds more work for maintainers to validate.
We weren't really using ViewsIcalHelper as a proper service before. This patch does that, but we weren't defining any arguments for ViewsIcalHelper in views_ical.services.yml. Adding:
arguments: ['@date.formatter', '@token.entity_mapper']
Sort of broke on me, because we have an implicit assumption that the token module is present and installed, but the views_ical module itself doesn't declare token as a dependency. I'm not really sure how to manage a soft dependency like that. While I'm hesitant to add new dependencies in general, token has over half a million installs, so this one might be alright. I had a question of what to do about the lock file update, since I can't really run composer commands to drupal module dependencies within the module, and it looks like the general practice is not to ship contrib modules with lock files. So I'll just remove that.
I'm getting an error with the Merge Request branch, on php 8.3.
$ curl https://views-ical.ddev.site/events.ics
The website encountered an unexpected error. Try again later.<br><br><em class="placeholder">ArgumentCountError</em>: Too few arguments to function Drupal\views_ical\ViewsIcalHelper::__construct(), 0 passed in /var/www/html/web/core/lib/Drupal/Component/DependencyInjection/Container.php on line 261 and exactly 2 expected in <em class="placeholder">Drupal\views_ical\ViewsIcalHelper->__construct()</em> (line <em class="placeholder">47</em> of <em class="placeholder">modules/contrib/views_ical/src/ViewsIcalHelper.php</em>). <pre class="backtrace">Drupal\Component\DependencyInjection\Container->createService() (Line: 179)
Drupal\Component\DependencyInjection\Container->get() (Line: 92)
Drupal\views_ical\Plugin\views\style\IcalWizard::create() (Line: 21)
Drupal\Core\Plugin\Factory\ContainerFactory->createInstance() (Line: 83)
Drupal\Component\Plugin\PluginManagerBase->createInstance() (Line: 824)
Drupal\views\Plugin\views\display\DisplayPluginBase->getPlugin() (Line: 941)
Drupal\views\ViewExecutable->initStyle() (Line: 921)
Drupal\views\ViewExecutable->getStyle() (Line: 482)
Drupal\views\Plugin\views\field\FieldPluginBase->defineOptions() (Line: 407)
Drupal\views\Plugin\views\field\EntityField->defineOptions() (Line: 143)
Drupal\views\Plugin\views\PluginBase->init() (Line: 110)
Drupal\views\Plugin\views\HandlerBase->init() (Line: 142)
Drupal\views\Plugin\views\field\FieldPluginBase->init() (Line: 218)
Drupal\views\Plugin\views\field\EntityField->init() (Line: 902)
Drupal\views\Plugin\views\display\DisplayPluginBase->getHandlers() (Line: 1099)
Drupal\views\ViewExecutable->_initHandler() (Line: 957)
Drupal\views\ViewExecutable->initHandlers() (Line: 2326)
Drupal\views\Plugin\views\display\DisplayPluginBase->preExecute() (Line: 1751)
Drupal\views\ViewExecutable->preExecute() (Line: 1686)
Drupal\views\ViewExecutable->executeDisplay() (Line: 81)
Drupal\views\Element\View::preRenderViewElement()
call_user_func_array() (Line: 113)
Drupal\Core\Render\Renderer->doTrustedCallback() (Line: 870)
Drupal\Core\Render\Renderer->doCallback() (Line: 432)
Drupal\Core\Render\Renderer->doRender() (Line: 248)
Drupal\Core\Render\Renderer->render() (Line: 153)
Drupal\Core\Render\Renderer->Drupal\Core\Render\{closure}() (Line: 638)
Drupal\Core\Render\Renderer->executeInRenderContext() (Line: 152)
Drupal\Core\Render\Renderer->renderRoot() (Line: 110)
Drupal\views\Plugin\views\display\Feed::buildResponse() (Line: 140)
Drupal\views_ical\Plugin\views\display\IcalDisplay::buildResponse() (Line: 56)
Drupal\views\Routing\ViewPageController->handle()
call_user_func_array() (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 638)
Drupal\Core\Render\Renderer->executeInRenderContext() (Line: 121)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext() (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 181)
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: 191)
Drupal\page_cache\StackMiddleware\PageCache->fetch() (Line: 128)
Drupal\page_cache\StackMiddleware\PageCache->lookup() (Line: 82)
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: 741)
Drupal\Core\DrupalKernel->handle() (Line: 19)
I would prefer to use getters and setters here. I went ahead and pushed a new commit which does that. Also removed a seemingly unnecessary line which was causing the warning joshuasosa pointed out.
Changing to needs to get some additional confirmation the updated patch works for other folks.
I assume it's added in the html head for early execution during the page load to avoid the flicker. Is there a way that CSP can include the nonce as an html head metatag? Does that conflict with also including it in the headers?
I'm testing out some updates to my CSP setup, and I get
Refused to apply inline style because it violates the following Content Security Policy directive: ... . Note also that 'style-src' was not explicitly set, so 'default-src' is used as a fallback.
(anonymous) @ toolbar.anti-flicker.js?v=10.2.5:62 I've created an issue in the CSP module issue queue here 🌱 Core Toolbar anti-flicker script adds inline style Active
So I figured out the issue, Search API Attachments adds a whole new field type to the fields you can add to be indexed, which appear as:
"Search api attachments: {My Files Field}" with the machine name "saa_field_{files}" -- curly braces replacing what would be your specific field name. While I had the standard field added to the index, which of course just ended up indexing as the file ID. It's mentioned in this part of the documentation:
"8. Go to admin/config/search/search-api/index/my_index/fields/add/nojs and:
- in the General section, add the "Search api attachments: My pdfs" field.
- in the Content section, add the "Title".
- in the Content section, add the "Body".
"
Which didn't jump out at me on my first several read throughs. I added this to be indexed, and it worked as expected.
Would it be unreasonable to request we update the documentation to call out that this is a new field, and not the standard file field?
You don't need to run this issue through ChatGPT. Just say you tested it, and looks good to you.
I'll take a look at the patch and merge if it looks good.
It seems like the js code is potentially already equipped to handle setting the cookie_flags value through the "Custom dimensions and metrics" from the back-end, but just based on the naming, it doesn't seem like that's not how it was intended to be used (also, the "dimensions' and "metrics" seem functionally identical here?).
I think I am running into this on what doesn't seem like a very large image (5100 × 3404 and 471K). The linked GD issue calls out some extremely large dimensions (specifically 60000x60000). But I am running into it on an Acquia host, with a memory_limit of 192M. With that said, it doesn't replicate in my local ddev environment with a matching memory limit.
I am running standalone GD 2.3.3 in ddev.
Acquia uses an older GD, 2.1.0 bundled with FreeType. The FreeType version they use (as of this comment, on the server I'm looking at) is 2.6.1. Is this even supported? I don't even see an available release for that at https://download.savannah.gnu.org/releases/freetype/?C=N&O=A
Are other's running into this issue exclusively on Acquia? Perhaps they just need to update FreeType/GD? But I'm finding it difficult to find documentation on what GD versions are bundled with what FreeType versions.
@Renrhaf How does this work? I don't see that this hook exists anywhere. The documented hooks in the 8.0-7.x version of the module are
- hook_elasticsearch_connector_load_library_options_alter
- hook_elasticsearch_connector_supported_data_types_alter
...and those are being removed in 8.x in favor of event subscribers. I'm struggling myself on figuring out how to alter ES queries to do just what OP is stating, boost by recency. Trying to do this has been challenging to figure out, as I assume I can alter the query with the query object. But it seems like what I actually need to do is add some additional parameters, similar to what Renrhaf is trying to do. When I try their example code, I get back zero results. Here is my non-working code at the moment. At least it doesn't break the query:
public function boostSearchByRecencyParams($event) {
//return;
$params = $event->getElasticSearchParams();
// Current time in milliseconds.
$now = time() * 1000;
$queryString = $params['body']['query'];
$params['body']['query'] = [
'function_score' => [
'score_mode' => 'sum',
'boost_mode' => 'multiply',
'functions' => [
[
'weight' => 1,
],
[
'weight' => 20, // Increase the weight to see a more significant boost
'gauss' => [
'created' => [
'origin' => $now,
'scale' => 365 * 24 * 60 * 60 * 1000, // 365 days in milliseconds
'decay' => 0.5,
],
],
],
[
'weight' => 10, // Increase the weight to see a more significant boost
'gauss' => [
'created' => [
'origin' => $now,
'scale' => 2 * 365 * 24 * 60 * 60 * 1000, // 2 years in milliseconds
'decay' => 0.5,
],
],
],
],
'query' => $queryString,
],
];
$event->setElasticSearchParams($params);
}
Perhaps the difference here is I am using the core "created" property instead of a date field, which is a unix timestamp instead of an actual date field in ES.
This is sorely needed, and the hooks are currently issuing deprecation warnings.
I would ask whether we should include the Search API events in the examples as well? Though this might be something better suited in the Search API module. I am noticing a trend where procedural hooks are still documented in *.api.php files, but newer plugins don't seem to have any clear documentation of their own.
I'm currently looking at a "search_api.query_pre_execute" event. which does give me the search api query, but I seem to be struggling to add any custom functionality via this means. I'd suggest having these hooks perform some small alteration examples as well, since I'm struggling to find any other simple documentation in this.
Greetings,
I was working in the other issue 💬 Is Maintenance Mode Redirect still maintained? Closed: outdated to add myself as a maintainer. I am still more than willing to be added here as well.
This issue is to add myself as co-maintainer of the Maintenance Mode Redirect ( https://www.drupal.org/project/maintenance_mode_redirect → ) module.
I haven't heard back from any of the maintainers. Just checking here one more time before I submit a request to become a maintainer?
I was testing out this module/patch. I seem to get this error, and it fails to generate the image:
Deprecated function: strtolower(): Passing null to parameter #1 ($string) of type string is deprecated in Drupal\avif\Controller\ImageStyleDownloadController->deliver() (line 79 of modules/contrib/avif/src/Controller/ImageStyleDownloadController.php).
I posted an update in the GitHub issue pointing to the other issue. I think it's still worthwhile to integrate with Purge, as that's the framework for accomplishing cache purges.
I do see some sparse documentation for the pantheon_clear_edge_paths() function here https://docs.pantheon.io/guides/wordpress-configurations/wordpress-cache... and in Pantheon's equivalent WordPress plugin https://github.com/pantheon-systems/pantheon-advanced-page-cache/blob/re... I would prefer using that then doing full CDN clears for obvious reasons.
I'm asking if someone from Pantheon can clarify the status of that function for general use, and also confirm the workflow for contributing to this module, since my GitHub pull request hasn't received any attention for two years, while the GitLab PR in the previously mentioned issue appeared to be merged within a month of being posted. While you are updating that paragraph on the module page, the Pantheon slack also recently consolidated slack channels into their single General channel, no more "Power Users" channel.
I suppose I'm not surprised that it deletes the view if it has a dependency on the module. I suppose this might be an issue for any module that provides a Views display plugin. This may be more of a core views issue than this module though. These issues seem similar, though not quite the same:
🐛
Config entities implementing EntityWithPluginCollectionInterface should ask the plugins to react when their dependencies are removed
Needs work
#3229138: When a view display is deleted, the dependencies list is not updated properly →
I'm not sure why it's not appearing on the module page, but there is a 2.0 release that appears to be compatible with Drupal 8 and 9. Not 10 however.
The module itself is very simple, and is just made up of a form alter for the maintenance mode admin page, and an EventSubscriber to set the redirect while in maintenance mode. It's a bit annoying that this isn't being actively maintained at the minimum of just bumping the core version compatibility. It would be nice if someone were willing to step in and take over maintainership. Since the module is so simple, it doesn't seem like much of a commitment.
In the meantime, I can get the ball rolling on that, and reach out to one of the listed maintainers to see if they are willing to add me as a co-maintainer.
FWIW. We ran into this issue with the Module Filter → module upgrading from 4.0.1 to 5.0.0. In that case, the module implements hook_update_last_removed(), after removing some update hooks.
Uninstalling and reinstalling the module appears to fix the issue.
Patch.
After applying the patch from my last comment, I saw there was an additional spot that needed an update.
Here is a patch with the change I proposed in my last comment. Not including an interdiff due to the simplicity.
I tried the patch in #11, and I still see my paragraph type labels cut off to 100px. I think that is because of this rule:
.js .paragraph-top {
grid-template-columns: 100px auto 1fr auto;
...
Is there any harm in using "auto auto 1fr auto" here instead?
I've started looking at this, one blocker I am running into is that they haven't yet implemented Recurrance Rules in Eluceo/ical 2.0. See this issue:
This should be in the new alpha13 release.
Whoopse, I committed that to the wrong dev branch.
This might have been a second usage that wasn't caught in #3133792: Call to deprecated function drupal_get_user_timezone() → . That patch was for src/Plugin/views/row/IcalFieldsWizard.php, but you are referencing views_ical.module. I admit, if we are already replacing references to a deprecated function, I should have checked the rest of the code base for any additional uses. So that's on me. Will go ahead and apply your patch.
@ravi, I'm not sure what you are saying/asking. Can you clarify?
@ravi,
The version control link is on the top of the theme page, here https://www.drupal.org/project/seven_dark/git-instructions →
The instructions from that page:
git clone https://git.drupalcode.org/project/seven_dark.git
cd seven_dark
Duplicate to #3209012: Move to eluceo/ical 2.0 → ,
Please post there if you would like to contribute.
Thank you for offering @mparker17, I'm not the maintainer, but looking into the status of this module. The ES 7 eol date may be as soon as this August, and from what I've seen, there is no progress on the 8.x-8.0.x version of this module. Which is sorely needed.
Hello, the purpose of this module is just to provide a report of the settings of your mysql server from within your Drupal admin reports page. If your are getting errors generally from your Drupal website, that is likely due to any number of configuration issues between the site and the database, and not an issue with this module. The error message you posted references the "sessions" table, which this module doesn't touch. The "MySQL server has gone away" is MySQL's generic error message and can mean many things. So I would suggest to discuss the issue you are seeing with your system or DB administrator.
The hook in the previous example doesn't work, in Drupal 10.1 at least, because the $variables['media'] variable shouldn't be a string. It should be an IFrameMarkup object. Setting it as a string like in the previous comment causes the embed to render as plain text markup, which is visible on the page. Instead, create a new object, with the value of the replaced string.
function hook_preprocess_media_oembed_iframe(array &$variables) {
$resource = $variables['resource'];
if ($resource->getProvider()->getName() === 'YouTube') {
// We are rendering a YouTube video, so modify the URL of the video so that it only shows related videos from the same channel.
// The video's markup is only available as a string, so we need to use str_replace() to modify the URL.
$new_string = str_replace('?feature=oembed', '?feature=oembed&enablejsapi=1', (string) $variables['media']);
$new_media = $variables['media']::create($new_string);
$variables['media'] = $new_media;
}
}
@NickDickinsonWilde
This token isn't working for me either. I can't enter "[color_field:rgba]" in the CSS Declaration config, because it fails validation due to not being a valid token. Even though "[color_field:rgb:rgba]" is what appears in the token information pop up.
I tried just modifying the color_field_tokens() function in color_field.module, and changed:
case 'rgba':
to
case 'rgb:rgba':
I assume this is because the token is defined like this in color_field_token_info():
$tokens['rgb']['rgba'] = [
As that seemed to be the pattern that multi-part tokens like this followed, and that worked for me.
I am using
Drupal core: 10.1.7
Color Field 3.0.0
I'm uploading a patch that applies a similar fix. Instead of replacing the case value entirely, I'm just adding a redundant one for "rgb:rgba" in case anyone previously entered the "[color_field:rgba]" value in fields whose tokens aren't validated.
I took a swing at properly checking values and using some null coalescing operators. Please test and confirm.
Apply to the "8.x-1.x" branch. not the "-dev" one. Which seems to erroneously be listed as the default dev branch on the module page.
With an update like this:
if ($transitionPrev !== null) {
around that block in ViewsIcalHelper, I get this sample output:
BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Drupal iCal API//EN
X-WR-TIMEZONE:UTC
BEGIN:VTIMEZONE
TZID:UTC
X-LIC-LOCATION:UTC
BEGIN:STANDARD
TZNAME:UTC
TZOFFSETFROM:+0000
TZOFFSETTO:+0000
DTSTART:20221024T201320
END:STANDARD
BEGIN:STANDARD
TZNAME:UTC
TZOFFSETFROM:+0000
TZOFFSETTO:+0000
DTSTART:20221026T081319
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
UID:Christmas
DTSTART;TZID=UTC:20231225T000000
SEQUENCE:0
TRANSP:TRANSPARENT
DTEND;TZID=UTC:20231226T115959
SUMMARY: Christmas
CLASS:PUBLIC
DESCRIPTION: Christmas
DTSTAMP:20231213T172851Z
END:VEVENT
END:VCALENDAR
For good measure, I set the site default timezone and my user's timezone preference to UTC. Does that seem like a valid output to you?
Reopening to address those warnings.
I'm not seeing the warnings myself, even with error reporting turned the way up, but that may just be the configuration in the ddev environment I am using.
Patch doesn't seem to cause issues. so going ahead and merging it. We can keep the issue open to look at the errors joshuasosa highlights.
I assume the error is being generated from this line:
$transitionPrev = $transitions[$transition['index'] - 1];
Where we are attempting to handle timezones for potential daylight savings. Based on the error, it sounds like the $transitions variable is null. I assume this is for a timezone that doesn't utilize daylight savings? We can do add some type checking here and just return.
Fixed.
I'm not opposed to it. Generally, the module is due for an overhaul, and this can certainly be a part of it.
It seems that if you have Replicate UI installed, with Feeds, in the feed settings, under the "Previously imported items: Select what to do with items that were previously imported, but are now no longer in the feed." setting, there are two seemingly similar options: "Delete" and "Delete Content". I believe "Delete" is the default core Drupal delete action, and "Delete Content" seems to map to an Action plugin in this module with the ID "entity_replicate:entity_node_replicate". Using that setting seems to utilize the EntityReplicate plugin that triggers the loop.
The simple solution seems to use the intended, "Delete" plugin instead of the one related to this module. But this does bring up a few new questions. Why is this plugin appearing in the first place? Why does the plugin ID, and label seem to refer to very different activities (deleting content Vs. replicating). What is the original intended use for the methods that seem to enter the loop and is it fulfilling that intent if it just enters an infinite loop?
For reference, here is the stack trace once it enters the loop:
EntityReplicate.php:69, Drupal\replicate_ui\Plugin\Action\EntityReplicate->execute()
ActionBase.php:22, Drupal\Core\Action\ActionBase->executeMultiple()
EntityReplicate.php:69, Drupal\replicate_ui\Plugin\Action\EntityReplicate->execute()
ActionBase.php:22, Drupal\Core\Action\ActionBase->executeMultiple()
EntityReplicate.php:69, Drupal\replicate_ui\Plugin\Action\EntityReplicate->execute()
EntityProcessorBase.php:374, Drupal\feeds\Feeds\Processor\EntityProcessorBase->clean()
LazySubscriber.php:123, Drupal\feeds\EventSubscriber\LazySubscriber->Drupal\feeds\EventSubscriber\{closure:/var/www/html/web/modules/contrib/feeds/src/EventSubscriber/LazySubscriber.php:120-128}()
ContainerAwareEventDispatcher.php:111, call_user_func:{/var/www/html/web/core/lib/Drupal/Component/EventDispatcher/ContainerAwareEventDispatcher.php:111}()
ContainerAwareEventDispatcher.php:111, Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch()
EventDispatcherTrait.php:38, Drupal\feeds\FeedsExecutable->dispatchEvent()
FeedsExecutable.php:284, Drupal\feeds\FeedsExecutable->doClean()
FeedsExecutable.php:115, Drupal\feeds\FeedsExecutable->processItem()
batch.inc:296, _batch_process()
batch.inc:138, _batch_do()
batch.inc:94, _batch_page()
BatchController.php:49, Drupal\system\Controller\BatchController->batchPage()
EarlyRenderingControllerWrapperSubscriber.php:123, call_user_func_array:{/var/www/html/web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php:123}()
EarlyRenderingControllerWrapperSubscriber.php:123, Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure:/var/www/html/web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php:121-124}()
Renderer.php:592, Drupal\Core\Render\Renderer->executeInRenderContext()
EarlyRenderingControllerWrapperSubscriber.php:124, Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext()
EarlyRenderingControllerWrapperSubscriber.php:97, Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure:/var/www/html/web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php:96-98}()
HttpKernel.php:181, Symfony\Component\HttpKernel\HttpKernel->handleRaw()
HttpKernel.php:76, Symfony\Component\HttpKernel\HttpKernel->handle()
RedirectMiddleware.php:44, Drupal\redirect_after_login\RedirectMiddleware->handle()
Session.php:58, Drupal\Core\StackMiddleware\Session->handle()
KernelPreHandle.php:48, Drupal\Core\StackMiddleware\KernelPreHandle->handle()
PageCache.php:106, Drupal\page_cache\StackMiddleware\PageCache->pass()
PageCache.php:85, Drupal\page_cache\StackMiddleware\PageCache->handle()
ReverseProxyMiddleware.php:48, Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle()
CloudFlareMiddleware.php:124, Drupal\cloudflare\CloudFlareMiddleware->handle()
NegotiationMiddleware.php:51, Drupal\Core\StackMiddleware\NegotiationMiddleware->handle()
StackedHttpKernel.php:51, Drupal\Core\StackMiddleware\StackedHttpKernel->handle()
DrupalKernel.php:704, Drupal\Core\DrupalKernel->handle()
index.php:19, {main}()
This is fixed in the alpha12 release.
Thank you for the patch, and apologies for the delay in getting to this. I'll commit this, and roll a new release shortly.
Apologies again to the brits in the timezone that this affected!
I was able to re-add the field just so I can run the update, and uninstall the module.
ALTER TABLE paragraphs_item_field_data ADD admin_title VARCHAR(255) NULL;
I ran into a similar error after updating drush and Drupal core. Clearing the cache/running database updates seems to have cleared it for me.
I didn't think that module supported Elasticsearch search back-ends with the connector module. In fact, I see this issue https://www.drupal.org/project/search_api_attachments/issues/2795755#com... → where the maintainer of this module commented that he had created this module to support that use case. Though it's a bit confusing as the issue is on supporting DB back-ends - which id din't know was possible either. That's the only issue in that module's queue that even mentions Elasticsearch.
Is it possible to get a new alpha release with this? Drupal 9 goes EOL in less than a month.
Hi emvl, Can you try formatting the link to your feed using the webcal protocol, e.g. "webcal://yourdomain.com/events.ics". This will prompt your browser to open the feed using your system default calendar app.
Attached patch can be applied to 5.0.6 (apologies, I know there are some changes in the current dev, which I realized after the fact).
It uses once to avoid attaching duplicate event handlers, and changes the call to close the modal.
For the OK, button, this module is using modal.modal('hide');
The current jquery modal documentation suggests using $.modal.close();, which appears to work as expected.
This might be a whole other issue, but looking at the modal-page.js code, I see that I end up with duplicate event listeners on the OK button. This should probably be wrapped in a "once" to prevent multiple even listeners from being attached to the same elements.