Thank you @agoradesign. Works as expected.
I've checked ->getBillingProfile()
usages over the code and haven't found any occurrences.
I confirm that patch from #15 works like a charm! +1RTBC
vlad.dancer → created an issue.
@claudiu.cristea I'm facing this issue too. Unfortunatelly I don't know how to reproduce it.
Here are some input:
We needed "id-less" data import. Well, actually migrate can't do that. But we decided to use
"row_index_column" field, provided by this module, and xls file_name as ids.
And migration config:
source:
plugin: custom_source_extends_url_source
data_fetcher_plugin: file
data_parser_plugin: custom_data_parser_extends_migrate_spreadsheet
track_changes: true
worksheet: 'Sheet1'
origin: A2
header_row: 1
item_selector: null
// Filled up on runtime
urls: []
columns: []
fields: []
# Actual ids for migrate source plugin will be next:
# - file_name
# - spreadsheet_row_index
ids:
spreadsheet_row_index:
type: string
row_index_column: 'spreadsheet_row_index'
The data imports fine, but batch reports result as error.
And after applying the patch now batch operation works without the error.
Just a small note.
Now, default value for the "Allow Embedding" setting is set to false. Anyway after module installation there is no default configuration that was imported on install, so setting this setting to false is quite expected.
The fix works and resolve this issue.
Nice idea! Changed.
For the moment I used this workaround: composer require phpoffice/phpspreadsheet:'2.2.2 as 1.29.1'
vlad.dancer → created an issue.
Thank you @duaelfr and @Matthijs for this plugin. We've used for a couple of years. It worked great.
But recently migrated to Drupal 10 and also changed some data import logic.
We needed "id-less" data import. Well, actually migrate can't do that. But we decided to use
"row_index_column" field, provided by this module, and xls file_name as ids.
Here is our migration config:
source:
plugin: custom_source_extends_url_source
data_fetcher_plugin: file
data_parser_plugin: custom_data_parser_extends_migrate_spreadsheet
track_changes: true
worksheet: 'Sheet1'
origin: A2
header_row: 1
item_selector: null
// Filled up on runtime
urls: []
columns: []
fields: []
# Actual ids for migrate source plugin will be next:
# - file_name
# - spreadsheet_row_index
ids:
spreadsheet_row_index:
type: string
row_index_column: 'spreadsheet_row_index'
And then we faced a number of issues with data parser plugin.
I'm not sure the roots of them, maybe updated migrate/migrate_plus/drupal apis.
But here are how we ended up using data parser plugin and fixed issues.
@claudiu.cristea was right about that file in openSourceUrl()
can come not only from remote, but from local fs.
Here how delt with it:
protected function openSourceUrl($url): bool {
$fetcher = $this->getDataFetcherPlugin();
if ($fetcher->getPluginId() === 'file') {
$this->configuration['file'] = $url;
}
else {
// Why we want to read file two times?
/** @var \GuzzleHttp\Psr7\Response $response */
$response = $this->getDataFetcherPlugin()->getResponse($url);
preg_match('/filename="(.*?)"/', $response->getHeader('Content-Disposition')[0] ?? '', $matches);
$this->configuration['file'] = $this->fileSystem->saveData($response->getBody(), 'temporary://' . $matches[1], FileSystemInterface::EXISTS_RENAME);
}
$this->initializeIterator();
return TRUE;
}
Next thing. In our case checking for an empty current item in valid()
was not enought. We got infinite loop.
So ended up with checking row_index_column and rows count:
public function valid(): bool {
$currentItem = $this->currentItem;
if (!$currentItem) {
return FALSE;
}
if (!parent::valid()) {
return FALSE;
}
// Check iterator for current/max index.
// Fix issue with lost last record.
$rowIndexCol = $this->configuration['row_index_column'] ?? NULL;
if ($rowIndexCol) {
$index = $currentItem[$rowIndexCol];
$max = $this->spreadsheetIterator->getRowsCount();
if ($index <= $max) {
return TRUE;
}
}
// Fallback to default check, which doesn't work for us,
// but should work for others if they use "row_index_column" feature.
else {
return $this->spreadsheetIterator->valid();
}
return FALSE;
}
BTW: there is also php notice for undefined row_index_column array key in SpreadsheetIterator class but I'll report this issue separately and link it here.
Ok, looks like there is no need to store an empty data inside $widget_context['ib_dam_media']:
"field" => array:3 [
"name" => null
"entity_type_id" => null
"entity_bundle_id" => null
]
when modal has been opened from CKEditor.
For now I'm accepting MR and put into my todo list optimising this case.
Thank for heads up!
Oh, I just realized that tugboat deployed Drupal with MR applied there. Ok, I need to test it on gitpod, without the MR.
@joegraduate I can't reproduce it with steps defined in issue's description. Check it here https://mr18-ofex2zwrcgdavguzjeqiezzieztdtign.tugboatqa.com/node/1 . No errors found in db log https://mr18-ofex2zwrcgdavguzjeqiezzieztdtign.tugboatqa.com/admin/report...
What additional steps did you do to get such errors? Which Drupal, module, php versions are you using? Have you configured settings here admin/config/services/ib_dam/media ?
BTW: "Select the downloaded image in the Media library" step is not necessary because after selecting asset in DAM modal it will be automatically downloaded and preselected in media modal.
vlad.dancer → created an issue.
I came here from
🐛
[1.15.0] bug, "Session has not been set" error thrown by select2_facets
Needs review
where ajax doesn't work after updating drupal core to 10.3+. While worked on solution I found code places in facets module where Request::create
beeing used too: facets/src/Controller/FacetBlockAjaxController.php
. So there is high chance that ajax facets won't wotrk too on drupal 10.3+. Probably because of changes in core/modules/views/src/ViewExecutable.php
It looks like @joao.ramos.costa and @svenseeberg have already expirienced this bug and can confirm it. Adding session is requred now (when dealing with views?):
$new_request = Request::create($path);
$new_request->setSession($request->getSession());
vlad.dancer → created an issue.
FYI: there is no Photoswipe Dynamic Plugin field formatter settings inside views field settings (when you select show fields and use Photoswipe as field formatter). For that you need to apply this patch 🐛 Formatter third party settings missing from Views UI Needs work
Commited into 1.0.x-dev
@Aditiup 16.92MB patch with over 234053 lines changed, is it purposely?
Regarding last commit in MR54 with +117/-168 changes in simplenews.module. These changes will never be reviewed/accepted at once.
We had the same problem with EntityBundle condition and it seems the commerce_product, menu_position, context modules could trigger such issue.
But nowadays (drupal 10.3.0) we have no problem on this page. It looks like somewhere in the mentioned module's releases this error has been fixed.
Looks like this has been fixed here 🐛 Custom Blocks with Layout Builder Enabled No Longer Use Front End Theme Fixed and added into 10.3.0, 11.x.
Thank you John for your advices.
In our case the one node didn't saved because there are so many inputs on the node form edit (entity references).
I took your suggestion about max_* php variables and compared local php setttings (phpinfo) with production one.
Increasing max_input_vars to 2000 helped us.
@mondrake, deviantintegral, @bradjones1 thanks a lot for your work!
Just I think after 5 years being open, there's no community interest at carrying this on. So I won't spend time on rerolls.
I'm working on a way of bringing UI to specify image styles beeing used for remote images for IntelligenceBank DAM → and I think this issue is a good base for it. Typically DAMs like IB or PicturePark provides a way to generate image derivatives on their side, but there is a lack for selecting right image style in content context (like ckeditor, specific node, block). In Drupal we have many ways to map content item with right display settings, but it fails if image is remote and we don't need generate derivative ourselfs.
I will check this issue more deeply!
@Anybody, sure, I just have no time for that. Maybe someone else can write them. One step a time to get further.
Hey @bobi-mel, thanks for your work! I reviewed it, looks great! I've worked on #3455963 on top of your code.
vlad.dancer → created an issue.
If you want to modify photoswipe formatter then you locked by #3301760.
Right now you can't use media tokens when using photoswipe field formatter on node for media entity reference field. That's because this code $entity_type = $imageDTO->getEntity()->getEntityTypeId();
(source) returns a host entity (node) when formatter being called from node rendering.
I have a similar situation but we are using paragraph for storing image with additional data. We're also using custom caption field but inside paragraph. I modified https://git.drupalcode.org/project/photoswipe/-/blob/5.x/modules/photosw... by this:
case 'custom':
$entity_type = $imageDTO->getEntity()->getEntityTypeId();
$entity = $imageDTO->getEntity();
$token = $thirdPartySettings['photoswipe_dynamic_caption']['photoswipe_caption_custom'];
// Try to extract parent entity type from token.
$token_parts = explode(':', str_replace(['[', ']'], '', $token));
$token_entity_type = $token_parts[0] ?? NULL;
// Let's use parent entity for token generation.
if (count($token_parts) > 1) {
$entity_type = $token_entity_type;
$entity = $imageDTO->getItem()->getParent()->getEntity();
}
$caption = \Drupal::service('token')->replace($token,
[
$entity_type => $entity,
'file' => $imageDTO->getItem(),
],
[
'clear' => TRUE,
'langcode' => \Drupal::service('language_manager')->getCurrentLanguage()->getId(),
]
);
break;
Keep it open for future findings by Project Update Bot.
Another quick workaround add hidden span tag <span class="hidden"> </span>
.
Here is a short video of the fixes:
Merge Request is welcome for testing.
vlad.dancer → created an issue.
@Nelo_Drup could you try this patch
🐛
Failed to open stream
Needs review
A bit later I will release a new dev version with many fixes that might cover your issue.
vlad.dancer → made their first commit to this issue’s fork.
Hey @AdamPS woud you mind to add git attribution into the commit or at least do this next time?
vlad.dancer → made their first commit to this issue’s fork.
This issue descibes only issue "TypeError: Drupal\menu_multilingual\Helpers::isMenuBlock(): Argument #1 ($block) must be of type Drupal\block\BlockInterface". And code guard if (!$build['#block'] instanceof BlockInterface) {
just added to prevent operating on non-block entity instances, that we need to add anyway.
@Jelle_S I'm not sure why you hardcoded settings for all block plugins in your patch.
dummy block entity doesn't have the third party settings
That's fine, because modules that are managing blocks should be responsible for making them compatible with core block related modules.
Here is example how context module added such compatibility:
- for adding 3rd party settings into block plugin edit form https://git.drupalcode.org/project/context/-/blob/5.x/src/Reaction/Block...
- for rendering block plugin https://git.drupalcode.org/project/context/-/blob/5.x/src/Plugin/Context...
I suggested for block_plugin https://git.drupalcode.org/project/block_field/-/merge_requests/16/diffs... to use the same approach.
> it worked with menu block (plugins) that were referenced by the block_field module
I think 🐛 Settings no longer stored as third party settings Fixed issue has been created in 2018 and lot's of code were updated in drupal core, context, block_field modules since that time.
Ok, looks like tests are not triggered for patches,
https://www.drupal.org/docs/develop/git/using-gitlab-to-contribute-to-dr... →
I assume it is better to use MRs.
Thanks @Jonasanne! Let's check if tests will be launched on status change.
@Jonasanne, @Jelle_S I followed described steps to reproduce the problem using DrupalPod with clean Drupal 10.2 and confirm getting this error too.
That's happens because block_field
deals with block plugins, but menu_multilingual
operates on block entities (normally created from block layout admin interface).
This means that other modules that use the same approach as we do are also do not work with block_field module. For example block_css.
I created here ✨ Provide a way to alter the block plugin configuration form Needs review initial patch to make it compatible with such module like this.
What we can do right now just to check block type and if it's not a block entity try to provide dummy block entity. Example:
public static function setBlockProcessing(&$build) {
/** @var \Drupal\block\BlockInterface $block */
$block = $build['#block'];
if (!$build['#block'] instanceof BlockInterface) {
$block = Block::create($build['#block']->getConfiguration() + ['plugin' => $build['#block']->getPluginId()]);
}
// ...
}
vlad.dancer → made their first commit to this issue’s fork.
For the moment developers can set language in the next way:
/**
* Implements hook_form_FORM_ID_alter().
*
* Set anonymous subscriber's preferred language based on current user interface.
* Fix Issue # 3447905.
*/
function mymodule_form_simplenews_subscriptions_block_[NEWSLETTER_ID]_alter(array &$form, FormStateInterface &$form_state): void {
if (\Drupal::currentUser()->isAnonymous()) {
array_unshift($form['actions']['submit']['#submit'], 'mymodule_alter_preferred_language');
}
}
function mymodule_alter_preferred_language(array &$form, FormStateInterface $form_state): void {
$form_state->setValue(['langcode', 0, 'value'], \Drupal::languageManager()->getCurrentLanguage()->getId());
}
Or even add language dropdown:
function mymodule_form_simplenews_subscriptions_block_[NEWSLETTER_ID]_alter(array &$form, FormStateInterface &$form_state): void {
if (\Drupal::currentUser()->isAnonymous()) {
array_unshift($form['actions']['submit']['#submit'], 'mymodule_alter_prefered_language');
$form['lang'] = [
'#type' => 'language_select',
'#title' => t('Preferred language'),
'#default_value' => \Drupal::languageManager()->getCurrentLanguage()->getId(),
'#languages' => LanguageInterface::STATE_CONFIGURABLE,
];
}
}
function mymodule_alter_prefered_language(array &$form, FormStateInterface $form_state): void {
$selectedLang = $form_state->getValue('lang');
$form_state->setValue(['langcode', 0, 'value'], $selectedLang ?? \Drupal::languageManager()->getCurrentLanguage()->getId());
}
Results for the test case:
// Switch to non default language.
$this->drupalGet('/es');
// Subscibe.
$this->submitForm($edit, 'Subscribe');
$subscriber = $this->getLatestSubscriber();
// Expect to get non default language
$this->assertEquals('es', $subscriber->getLangcode(), 'Subscriber prefered language is set to user interface language');
vlad.dancer → changed the visibility of the branch 3.x to hidden.
vlad.dancer → created an issue.
I merged 4.x into MR40 and fixed tests. To address issue with ellipsis reported here #15 I corrected regex to continue looking for a right url. It seems that we have a correct email link, but at the bottom of email:
We have received a request to subscribe xSdv@xzcz.yuk [1] at
https://8080-project-drupalpod-8rrv90s5k2j.ws-eu111.gitpod.io/ [2]. To
confirm please use the link below.
https://8080-project-drupalpod-8rrv90s5k2j.ws-eu111.gitpod.io/simplenew…
[3]
[1] xSdv@xzcz.yuk
[2] https://8080-project-drupalpod-8rrv90s5k2j.ws-eu111.gitpod.io/
[3]
https://8080-project-drupalpod-8rrv90s5k2j.ws-eu111.gitpod.io/simplenews/confirm/8/1715954779/5AZSMrLlUXg1OAHNKTL4J9uB9qkFeGetnRW8-KqSfdw
vlad.dancer → made their first commit to this issue’s fork.
I confirm that patch from #10 is needed for 3.x version and in 4.x there is no such problem.
Hey @devil2005 you can require d10 compatible module version in the next way:
composer remove drupal/ckeditor_uploadimage
Then edit composer.json:
{
"type": "package",
"package": {
"name": "drupal/ckeditor_uploadimage",
"type": "drupal-module",
"version": "dev-2.x",
"source": {
"type": "git",
"url": "https://git.drupalcode.org/issue/ckeditor_uploadimage-3296782.git",
"reference": "f87155bc4d671a6763b93c49bd0bececcd37d763"
}
}
},
And place the above right before:
{
"type": "composer",
"url": "https://packages.drupal.org/8"
},
{
"type": "composer",
"url": "https://asset-packagist.org"
},
Then run composer require drupal/ckeditor_uploadimage:dev-2.x
The last step you might need to run two times.
Created 1.0.0 release for Drupal 9/10 and dropped d8.
Also created Drupal 10+ release as main module version.
Applied bot's patch in 2.x branch.
vlad.dancer → made their first commit to this issue’s fork.
This patch incorporates previous changes plus makes compatible with
Drupal 10 version of datetimehideseconds module
🐛
Doesn't hide seconds on Drupal 10
Fixed
(in dev branch).
There are few more minor adjustments:
date_all_day.js:
- used core/once library to attach drupal behaviour once,
- added workaround to prevent browser of running time input validation when seconds are not hidden.
Patches' interdiff is in place.
Thank you @trackleft2 and @joegraduate!
Well, it seems #54 can't be applied to 2.1.x anymore.
So here is a re-roll of it for 2.1.x.
vlad.dancer → created an issue.
Here is a patch that foes next things:
- for field widget: adds js setting to hide seconds when datetimehideseconds is enabled and configured to hide specific field.
- for field formatter: add new condition to check
23:59:00
time and assume it as valid "all-day" time format.
The correct token is: [commerce_order:shipments:0:entity:shipping_profile:entity:address]
Here is a patch with using renderPlain() instead of render() because sometimes we're having the next error:
LogicException: Render context is empty, because render() was called outside of a renderRoot() or renderPlain() call
I have the same problem (Drupal 9.5.11). Thank you @Grayside for identifying it!
For the moment I removed sorting on paged query to avoid duplicates.
Replaced old isMasterRequest
method with correct one - isMainRequest
Removed deprecated "@app.root" in favor of "%app.root%"
Updated info.yml files on top of patch from #3.
Here is a patch to make module compatible for Drupal 10, based on previous one.
Here is a patch for Drupal 10 compatibility based on the patch for Drupal 9.
I've tested MR (14) too. Works good!
But it took "ages" to sync 170K entities (and we have even more for other cer instances). I tested it on DigitalOcean premium amd ssd.
My workaround was to increase number of items per batch operation:
public function submitForm(array &$form, FormStateInterface $form_state) {
$batch = new BatchBuilder();
$batch->setTitle(t('Synchronizing the values for corresponding reference %label', [
'%label' => $this->entity->label()
]));
$idsToSync = $this->getEntityIdsToSync($this->entity);
$i=0;
foreach ($idsToSync as $entityTypeId => $ids) {
foreach ($ids as $id) {
$to[] = [$entityTypeId, $id];
$i++;
if ($i % 20 == 0) {
$batch->addOperation([$this, 'doSyncEntity'], [$to]);
$to = [];
}
}
}
batch_set($batch->toArray());
$this->messenger()->addStatus($this->t('Corresponding reference %label has been synchronized.', [
'%label' => $this->entity->label(),
]));
}
public function doSyncEntity(array $entities): void {
foreach ($entities as [$entityTypeId, $entityId]) {
$entity = $this->entityTypeManager
->getStorage($entityTypeId)
->load($entityId);
cer_sync_corresponding_references($entity);
}
}
What do you think about making chunk size adjustible?
Also I think in our case we know more or less how many nodes we need to sync (between X and Y days) so I'm thinking to write VBO plugin → to use views then for filtering and avoiding full cer re-sync.
No, that's wrong assumption. The key is different then.
Compare:
-
const location_field = 'field_p_kb_inst_address[0][subform][field_kb_geolocation]'; jQuery(document).find("input[name*='"+location_field+"[0][value][lat]']");
Object { 0: input#edit-field-p-kb-inst-address-0-subform-field-kb-geolocation-0-value-lat--HfLvn8mw3Ag.geofield-lat.form-textfield.form-control, length: 1, prevObject: {…} }
-
const location_field = 'field_kb_geolocation';
jQuery(document).find("input[name*='"+location_field+"[0][value][lat]']");
Object { length: 0, prevObject: {…} }
vlad.dancer → created an issue.