🇸🇰Slovakia @lubwn

lubwn → created an issue.

For anyone stumbling upon this issue the answer is [0] instead of "0", basicly just put brackets there and it gets parsed just fine. Not sure why. Probably 0 = false in normal context or so.

Oh well I personally do not like Migrate module or Drush that much so I can not help you there. I would try Migrate module via GUI of Drupal without Drush but this is where my knowledge ends. Only thing I like Migrate about is keeping passwords for accounts untouched. Most Drupal sites are way too customized and has way too many uncompatible modules for Migrate module to handle that.

Hi, format does not matter, pick whichever you prefer but to import nodes with corresponding authors you need to have a way to connect those two between the imports.

When I am doing such migrations I tend to create hidden field like "old_uid" or something on new Drupal 9 site to store UID of authors from old Drupal 7 site and use that field as connector between newly imported articles and authors. You can also use names of authors or emails if you prefer but I found having UID which is always unique is the best way.

To do that, you need to:

1. Export authors from old Drupal 7 instance, export all the fields you wish but do not forget to export UIDs as well

2. Create the field "old_uid" on new Drupal 9 instance under User entity

3. Create new importer via feeds module and import authors from old website to new website while mapping UID to field "old_uid" on User entity

4. Export articles from old Drupal 7 instance using Views Data Export module in a format you prefer (be it JSON, XML, CSV etc. it is up to you). Do not forget to add relationship to author in Views and add UID to each article as a field, so you export UIDs of authors as well

5. Create new importer via feeds module and import nodes from old website, mapping UID field from export to relationship of author's "old_uid" field. This is done in feeds GUI where you can set up Author (uid) field and reference to "user.field_old_uid" so you create cross-entity reference to right field.

This way you should be able to transfer both authors and nodes to new website.

If you happen to have the authors already imported and with to import only nodes, you can do the same but instead of mapping via "old_uid" field you can map authors by name or e-mail, which also should be unique but in some instances of Drupal 7 it might not be.

I hope that helps.

Solution from #61 worked for me. Installing with composer command solved the issue:

composer require 'drupal/recaptcha:^3.0'

I have older Drupal 8.9.x website where update would be problematic so I installed recaptcha at first by hand, but came across this error.

I duplicated composer.json file somewhere locally, run the command, copied vendor directory to live website and it started to work.

Depends really on the setup of your filters. Which filters are you using and what is the configuration of your site? Are you using any relationships in your views? Are you filtering based on taxonomies? 

I also had this problem and made an issue in colorbox module queue. For me it was not working when caching was enabled. Somehow cache was adding subdomain to my URLs in colorbox so naturally it failed to load. I fixed this with JS in the end as a quick fix.

Try to disable cache and see if it helps. However, I doubt your problem will be the same. Double-check the URLs of the colorbox images and see if they changes and whether the image is actually present or not in the directory.

Hi, I know this is a bit late reply but I would go with Views Data Export module to export all the nodes from Drupal 7 site in a format I would prefer (CSV / XML, up to you) and with fields I would like to import and then import them using Feeds module as you specified.

It is worth noting that using Migrate module will save you a lot of time if nodes are more complicated - like, for example, if your website had multiple users posting each under their name Migrate module will automatically pair the nodes to their authors and import authors as well, alongside with passwords, it will also import media like images, videos etc. Using Views Data Export you have full control over what and how you want to migrate but also burden of matching proper nodes to proper authors is on you.

lubwn → created an issue.

Sadly this is an error which seems to be too deep to be fixed in short term so I developed custom solution.

I have basicly only added new custom fields with same names as taxonomy fields I already had but with formatter "Text (plain)". Then I used hook_entity_presave() to match text inputted by user into those custom fields and check whether taxonomies exists by name or not, setting them to previously created taxonomy reference fields as target_id. In this custom solution you also have full control over what you want to use as a delimited between each taxonomy entity (for example ";" instead of "," or so)

I guess proper "Drupal" way would be either somehow fix the error or create custom taxonomy field formatter with the logic needed for that but to be fair that would take so much more time and effort as everything with Drupal that those custom hacks works better and are faster to implement.

Sadly this does not work in Drupal 9.5.9 at all. Putting any text in parentheses triggers an error so entities containing text in parentheses can not be referenced at all (nor created). Applying patch from #18 does not solve the issue.

I have a very big query with lots of sorting and exposed fields so I was not comfortable with adding custom query to this, potentionally breaking things.

I came up with elegant solution without coding. You basicly only need to know which multi-valued field is creating the duplicates. Often it is some taxonomy or entity reference or reference to image field or so, and then you just add filter with DELTA lower than 1. This will eventually filter-out the duplicates completely. No aggregation or coding needed.

Okay I solved this issue. It had probably nothing to do with colorbox at all but I am not sure. It looks like links to colorbox were rendered with subdomain instead of main domain. So basicly I had all the thumbnail images loaded properly with links like https://domain.tld and links were rendered with https://sub.domain.tld instead of only pointing to main domain.

I am still not sure what triggered that, it looks like it has something to do with how the server is set up.

Since I had no time digging into the server stuff and this was the only field having the problem I solved it in theme JS file with the following code:

$('a[href^="https://sub."]').each(function(){ 
	var oldUrl = $(this).attr("href"); // Get current url
	console.log(oldUrl);
	var newUrl = oldUrl.replace("https://sub.", "https://"); // Create new url
	$(this).attr("href", newUrl); // Set herf value
});

I am just leaving the code here although it is highly unlikely someone will have the same problem.

Patch from #2 works good for me. Thanks a lot!

Applying patch from #25 worked in my case as well. Tested on Drupal 9.5.

It is also worth noting that this functionality is crucial in accessibility. I was specifically searching for the solution because my videos refused to play on iphone devices. Having "autoplay" and "muted" is apparently not not enough for iphones and instead of at least showing the video with play button it simply decides to not render video at all, leaving the space blank. Adding "playsinline" from the patch actually solved the problem.

In my case I was getting error because Drupal is behind reverse proxy. My problem is that it is a bunch of different servers all pointing to different subdirectories, while I do not have an access to the main server where the main website lives.

So in my case I did not need to "remove" the subdirectory but ADD the subdirectory instead. Which worked, but also resulted in TrustedRedirect errors.

My settings.php file is:

$trim_path = '/subdirectory';
if (isset($GLOBALS['request'])) {
  $request = $GLOBALS['request'];
  if ($request->server->get('SCRIPT_NAME') == "/index.php") {
    $request->server->set('SCRIPT_NAME', '/subdirectory/index.php');
	$request_uri = $trim_path . substr($request->server->get('REQUEST_URI'), 1);
	
	$request->server->set('REQUEST_URI', $request_uri);
  }
}

To fix trustedRedirect errors I used rather stupid jquery front-end fix, but it works:

/* Fix trustedRedirectResponse */
$( document ).ajaxComplete(function (event, xhr, settings) {
	
	$("a").each(function() {
		$(this).attr("href", $(this).attr("href").replace("edit?destination=/node/", "edit?destination=/subdirectory/node/"));
	});
	
});

I had trouble in ajaxified views, which lead to wrong redirects but it was all in GET parameter, so this basicly just replaces href attribute with proper URL.

I was searching for that and google gave me answers like I need to code it myself using phpexcel library. There is a thread on stackexchange from like year 2016 which states that (probably it was not available back in the day). I stumbled upon this issue thread randomly. I think this should definitelly be mentioned on a project page. Most of the time I expect readme file be the same as project page file and rarely open it.

I had this error with jquery_ui_slider and indeed as stated in #27 actually downloading the module and enabling it, even when not used anywhere on the website it solved the errors present in dblog / occasionaly presented on frontend.

I wonder why / how this happens but so far this is a good solution for me.

Thanks I just needed this in time. I installed -dev and it works flawlessly!

I am also running into this problem. Clearing the cache indeed solves the issue. This is definitely not fixed nor duplicate if the problem still occurs.

Confirming #18 works for me. I have drupal set up behind reverse proxy and in fake subfolder so I have some funky staff going on in settings.php file to account that.

I am running into the same problem. Not sure what triggers it yet. I have slick carousel on homepage as well and also ajax pager for some content so I guess one of those triggers it. But also apart from errors in the console everything seems to be working just fine.

I have also solved this by adding yoast_seo.js to libraries.yml file of my theme.

But I am not sure if I did it right, my code is:

global-styling:
  version: VERSION
  css:
    base:
      css/adminimal.css: {}
  js:
    /modules/contrib/yoast_seo/js/yoast_seo.js: {}
    js/scripts.js: {}
  dependencies:
    - core/jquery
    - yoast_seo/yoast_seo_admin
    - yoast_seo/yoast_seo_core

So I wrote the path from root as I have no idea how to include this from module / library perspective. But it works.

This exactly happened to me as well. I set the confirmation message to "no redirect" on webform block setting instead of webform form setting.

I just switched "Confirmation message" in webform block setting to "Display as configured in the webform" and in webform settings page under Form settings -> Redirect location -> No redirect (reload current page) and it fixed the problem.

So basicly nothing changed from user-perspective but somehow it fixed the problem.

Cool thanks a lot! I used hook_metatags_alter() to that purpose. For everyone needing the same / similar solution I will just leave the code I wrote here, maybe it will help someone.

<?php

/**
 * Implements hook_metatags_alter().
 */
function YOURMODULE_metatags_alter(array &$metatags, array $context) {
  
	if (isset($context["entity"]->product_id)) {
		
		$product_id = $context["entity"]->product_id->value;
		
		$review_ids = \Drupal::entityQuery('comment')
		   ->condition('entity_id', $product_id)
		   ->execute();
		   
		// Blank metadata
		$metatagData = [];   
		$metatagReviews = [];
		
		if(!empty($review_ids)) {
			
			$reviews = \Drupal::entityTypeManager()->getStorage('comment')->loadMultiple($review_ids);
			
			$numberOfRatings = 0;
			$totalRating = 0;
			
			foreach($reviews as $review) {
				
				// 0 - 100
				$rating = $review->field_fivestar->getString();
				
				$totalRating += $rating;
				
				$numberOfRatings++;
				
				if ($numberOfRatings < 10) {
					
					$reviewData = [];
					$reviewData["@type"] = "Review";
					
					$reviewData["datePublished"] = \Drupal::service('date.formatter')->format($review->created->value, 'custom', 'Y-m-d');
					
					$reviewData["name"] = $review->comment_body->value;
					
					if (strlen($review->comment_body->value) > 80) {
						$reviewData["name"] = substr($review->comment_body->value, 0, 80) . '...';
					}
					
					$reviewData["reviewBody"] = $review->comment_body->value;
						
						$author = [];
						$author["@type"] = "Person";
						$author["name"] = $review->getOwner()->name->getString();
						
					$reviewData["author"] = $author;
					
						$reviewRating = [];
						$reviewRating["@type"] = "Rating";
						$reviewRating["ratingValue"] = $rating / 2 / 10;
						$reviewRating["bestRating"] = "5";
						$reviewRating["worstRating"] = "1";
					
					$reviewData["reviewRating"] = $reviewRating;
					
					array_push($metatagReviews, $reviewData);
					
					
				}
				
			}
			
			$metatagData = unserialize($metatags["schema_product_aggregate_rating"]);
			
			$calculatedRating = $totalRating / $numberOfRatings;
			
			$metatagData["ratingValue"] = $calculatedRating / 2 / 10; // 80 / 2 / 10 = 4 stars
			
		}
		
		$metatags["schema_product_aggregate_rating"] = serialize($metatagData);
		$metatags["schema_product_review"] = serialize($metatagReviews);
		
	}
	
	// \Drupal::logger('my_module')->notice('<pre>&#039; . print_r($metatags, TRUE) . &#039;</pre>');
	
}

Yes I know this is not the ideal solution but it works for now.

lubwn → created an issue.

Patch from #23 works flawlessly on 8.x-1.0-beta11, I suggest including this in new release, it is a good feature! Thanks a lot

For whoever stumbled upon this issue I have a coding solution, you can basicly use HOOK_views_query_alter() to add nested WHERE condition to your already existing views query.

You have to actually use $query->addWhereExpression() from QueryPluginBase class to achieve that.

It basicly gives you the freedom to write whatever query you see fit in WHERE condition, and is incredibly easy to debug (you simply turn-on views SQL queries in views settings and after each "update preview" button you see the executed query no matter how bad or good it is)

Code I have used goes as follows:

use Drupal\views\ViewExecutable;
use Drupal\views\Plugin\views\query\QueryPluginBase;

function MYMODULE_views_query_alter(ViewExecutable $view, QueryPluginBase $query) {

	if ($view->id() == 'YOUR_VIEW_ID') {

		// Add LEFT JOIN to First Field
		$configuration = [
		  'table' => 'node__field_YOUR_FIELD_NAME',
		  'field' => 'entity_id',
		  'left_table' => 'node_field_data',
		  'left_field' => 'nid'
		];
		$join = Drupal::service('plugin.manager.views.join')->createInstance('standard', $configuration);
		$query->addRelationship('node__field_YOUR_FIELD_NAME', $join, 'node_field_data');

		 // Here you can add LEFT JOIN to second field...
		
		/*
		 * VIEWS ALTER LAYOUT:
		 *
		 
		- Exposed Filters -
		AND
		(
			(
				Field 1 = Value 1 AND
				Field 2 = Value 2
			)
			OR
			(
				Field 2 = Value 3
			)
		)

		// Here you basicly write whatever will run inside WHERE clause in query
		$queryExpression = "
		(
			(node__field_YOUR_FIELD_NAME.field_YOUR_FIELD_NAME_value IN('1'))
			AND
			(node__field_SECOND_FIELD_NAME.field_SECOND_FIELD_NAME_value IN('2'))
		)
		OR
		(
			node__field_SECOND_FIELD_NAME.field_SECOND_FIELD_NAME_value IN('3')
		)
		";
		
		$group_id = $query->setWhereGroup('AND');
		$query->addWhereExpression($group_id, $queryExpression);
		
	}
	
}

Downsides are that you need to write your own JOINs, because if there is no filter added by Views UI you have no access to fields you probably need, so I left the relationship in code above.

I searched the whole internet for the solution and this is the closest and arguably easiest way to achieve nested groups in current views version. It would be a nice addition in UI but I doubt it will ever happen, seeing this is not the feature many needs. Hope the code helps someone in the future.

Thank you @angrytoast for patch from #121, works flawlessly on Drupal 9.4.8

I actually stubled upon this issue when writing my own module and adding some fields programativally to fieldset created by form_group module. I am unable to set weight of field programatically on a field which is wrapped in fieldset by admin UI.

I can actually solve this by simple JS on client-side but I wanted to solve this in backend. What is the proposed resolution in this case? Can my form alter hook run after the field_group module form alter hook?