Quantcast
Channel: Issues for Drupal core
Viewing all 294734 articles
Browse latest View live

Update block library page to adapt publishable block content implementation

$
0
0

Problem/Motivation

Custom blocks are now publishable, but the Custom block library page (/admin/structure/block/block-content) doesn't not reflect this change. Since the custom blocks as publish-able, make the UI close to node admin page (/admin/content):

This work was started In #2834546: UI for publishing/unpublishing block_content blocks, but it was decided to split the changes to block_content view and related into a follow up issue, because this requires an upgrade path.#2834546: UI for publishing/unpublishing block_content blocks should be committed before this issue gets in.

Proposed resolution

Introduce below changes:
1. Bulk operation form
2. Add published column
3. Add publish status filter

and write the upgrade path in this issue.

Remaining tasks

- Implementation - Done
- Manual testing - Done
- More reviews
- Commit!

User interface changes

Adds a bulk publish / unpublish actions and a new "published" column to the Custom block library page /admin/structure/block/block-content

API changes

None

Data model changes

None


Add back rollbacks through the UI

$
0
0

Follow-up to #2687843: Add back incremental migrations through the UI

Problem/Motivation

Follow-up to #2683421: Remove incremental and rollback options from the UI (and add them back when they are more stable) which removes both the rollback and incremental options since they were untested and had several significant bugs. Unlike the incremental migration feature, rollback can probably be considered an additional feature and not necessarily block a stable Migrate UI.

Proposed resolution

Add back rollback migration support to the UI, with test coverage.

Use the phrase 'incremental upgrade' instead of 'Rerun' as shown in the now dated screenshot. See #32

Documentation to the handbook will be covered in a follow-up issue #2947498: Document Migrate Drupal UI rollbacks.

Remaining tasks

Documentation to the handbook will be covered in a follow-up issue #2947498: Document Migrate Drupal UI rollbacks.

User interface changes

In #2683421: Remove incremental and rollback options from the UI (and add them back when they are more stable), the UI disallows both incremental migrations and rollbacks. Here is what it looked like before that:

We might want to either reimplement that, or change it.

API changes

Depends on the solution.

Data model changes

None

Postponed until

UI for publishing/unpublishing block_content blocks

$
0
0

Problem/Motivation

In #2820848: Make BlockContent entities publishable blocks got a publishing status field, but no UI. We should provide a way for users to (un)publish blocks when editing/creating them.

Changes to the block library page have been split off to to #2909435: Update block library page to adapt publishable block content implementation

Proposed resolution

Add the published checkbox to the block edit form like on other editorial content entities.

Remaining tasks

  • Implement it
  • Provide upgrade path & test

User interface changes

Yes.

Status checkbox on the block content form

API changes

None.

Data model changes

None.

JS: Polyfills support

$
0
0

Problem/Motivation

Right now we don't have a solid plan for how we can handle polyfill support.

Proposed resolution

For now, I see a few options:

1. Include the appropriate polyfills manually:

We can provide one file (e.g misc/polyfills.es6.js) which includes needed polyfills (most probably used from https://github.com/zloirock/core-js).

This file will be loaded as the first one before any other JS files.

The similar approach was done by CRA.

2. Add https://polyfill.io/

What we need is just add one js file before any others:
<script src="https://cdn.polyfill.io/v2/polyfill.min.js"></script>

But it seems polyfill.io is a good service with bad polyfills (different authors/projects which doesn't well play together).

3. Configure https://babeljs.io/docs/en/babel-polyfill

It's quite heave. But will include all needed polyfills. Need more investigation.

4. Configure https://babeljs.io/docs/en/babel-plugin-transform-runtime

This solution will add polyfills automatically only when needed (based on target browsers from babel-present-env).

But, that's something which depends on require or import - we don't support it ¯\_(ツ)_/¯

5. Any others?

Remaining tasks

1. discuss with community
2. write solution
3. review
4. 🎉

[Add third party library] HTML attributes handling

$
0
0

Hi all,

I've been working on a library these last days: HTMLTag.

This library handles the creation of HTML tag and its attributes.

Drupal has a class to handle its HTML tags Attributes.
That class could be replaced by the Attributes class from HTMLTag.

HTMLTag is friendly to use and has full tests coverage and tests related to the attributes handling could be removed from Drupal.

I made a proof of concept locally and uploading the patch here, just as a proof of concept, tests on that patch are not yet removed.

It's the first time I propose an external library for Drupal core, I don't know if it's the right way, let me know if this is worth continuing.

Thanks.

Field config returns translatable === true if on a bundle that is not translatable

$
0
0

Problem/Motivation

Say you have a field on both the article and basic page bundles but only the article bundle is translatable. Calling isTranslatable() on the field config for the basic page bundle will return true. This is the problem. If the basic page bundle becomes translatable (but not the field itself), isTranslatable() correctly returns false. So basically, as @plach said, the translatability is inherited from the field storage if they are not configured in the UI.

Proposed resolution

I believe it doesn't make sense for a field config to call itself translatable if it is in fact not. But I also probably am missing a lot of context info as to why this is. So it's very much open to discussion.

Remaining tasks

Discuss this issue and come to an agreement on the matter.

User interface changes

None.

API changes

Unclear.

Original report by @Upchuk

Migrate support for deleting items no longer in the incoming data

$
0
0

Problem/Motivation

We would like to add support for deleting items that are no longer present in the incoming data when a migration is run. This was a feature of Feeds in D7 and seems like a common need.

Proposed resolution

From @mikeryan in #15:

I really think this should be a distinct "purge" operation that gathers the currently-available source IDs from the source plugin, and scans the map table for any which aren't in that list to invoke the destination rollback on them. Now that I think about it, maybe it could even be an option on rollback - drush migrate-rollback --missing-from-source my_migration.

Remaining tasks

Add tests.

User interface changes

API changes

Data model changes

UpdatePathWithBrokenRoutingFilledTest doesn't see updated database

$
0
0

I made patch to the core Ban module - https://www.drupal.org/files/issues/2018-09-19/range_ip_ban-2972332-13.p... . Published to https://www.drupal.org/project/drupal/issues/2972332 . My patch add new field ip_end to the ban_ip table by using hook_update and the patch add new features using this new field. Test showed errors 'Unknown column 'ban.ip_end'', the test don't see new field.

I tried change query type from db_query to dynamic type, then change db_add_field() to construction like:

$database = \Drupal::database();
$schema = $database->schema();
$spec = [
  'description' => 'IP address (end of range if not empty)',
  'type' => 'varchar_ascii',
  'length' => 40,
  'not null' => TRUE,
  'default' => '',
];
$schema->addField('ban_ip', 'ip_end', $spec);

That code like code whitch used on /core/modules/system/system.install.

This patch successfully applied on the local site and on the hosted sites.
So, I don't understand what I have to do with my patch. Maybe something wrong in UpdatePathWithBrokenRoutingFilledTest because I have error from this test only.


[policy, no patch] Make removal of deprecated usages a feature release blocker

$
0
0

https://www.drupal.org/node/2941566

contributed and custom project maintainers are encouraged to keep up with core deprecations each minor release, so that the work to make projects compatible with the next major release will be minimal.

It means contrib maintainers are encouraged to remove usage of deprecated code, but Drupal core is not doing it.
Code inspection of the core folder for Drupal 8.5.0-rc1 found 19175 warnings where deprecated code is used. This is unacceptable.
If we really want to convince anyone that continuous upgrades for Drupal is a real thing, then this problem must be fixed.
Contrib maintainers do not care about deprecations when core looks like this. D9 (the next Drupal major release) will just break almost all the contrib, and continuous upgrades will be mentioned as "it was a nice idea"..

My proposal is to do not release Drupal 8.6 until there is 0 usage of deprecated code.

Replace all calls to db_select, which is deprecated

States API doesn't work with multiple select fields

$
0
0

The States API won't pick up the value of a select field with #multiple = TRUE option.

Steps to reproduce:
- Create two fields in a form with the following code:

  $form['dependee'] = array(
    '#type' => 'select',
    '#options' => array(
      'a' => 'Option A',
      'b' => 'Option B',
      'c' => 'Option C',
    ),
    '#multiple' => TRUE,
  );

  $form['dependent'] = array(
    '#type' => 'textfield',
    '#states' => array(
      'visible' => array(
        'select[name="dependee[]"]' => array('value' => array('a')),
      ),
    ),
  );

The dependent field will stay hidden regardless of the value of the dependee. This happens because the value of a multiple select field is an array, and States tries to compare it with the reference with a === operator, which returns always false.

The proposed solution is to add a handler for arrays in states.Dependent.comparisons. This works with ANDed values:

'select[name="dependee[]"]' => array('value' => array('a', 'b')),

and with ORs as well (following the syntax proposed in #735528: FAPI #states: Fix conditionals to allow OR and XOR constructions):

'select[name="dependee[]"]' => array(array('value' => array('a')), array('value' => array('c')))

Before

After

ModuleHandler::parseDependency() can deal with beta1 but not beta

$
0
0

Problem/Motivation

As part of refactoring and improving Drupal's harmony with semver, it's been discovered that ModuleHandler::parseDependency() expects dev versions to end with a number.

For instance, views_ui(8.x-1.1-alpha12) can be parsed, but views_ui(8.x-1.1-beta) can not.

That's because the regex looks like this: $p_minor = '(?<minor>(?:\d+|x)(?:-[A-Za-z]+\d+)?)';

You can see this reflected in the test data: https://cgit.drupalcode.org/drupal/tree/core/tests/Drupal/Tests/Core/Ext...

Proposed resolution

Figure out if this matters.

Change it.

Remaining tasks

User interface changes

API changes

Data model changes

Consider use of Media audio in Umami demo

$
0
0

Problem/Motivation

Now media is available, we should consider how to implement its audio handling capabilities in Umami.

Proposed resolution

Decide if and how to showcase this. Should we include audio recipes? Or audio versions of articles? Should they be mandatory, or just available on a subset? Is there a way to flag content with audio so that those with relevant accessibility issues can find it?

Remaining tasks

All the things.

User interface changes

TBD

API changes

None

Data model changes

None

Impossible to update an entity revision if the field value you are updating matches the default revision.

$
0
0

Problem/Motivation

Use case:

  1. Doing a batch update of all entity revisions to fix some field values (all revisions must be fixed because of content moderation, drafts and published revisions need to be updated).
  2. Iterate over all revisions, update entity value and call save.
  3. Encounter the following code in \Drupal\Core\Entity\Sql\SqlContentEntityStorage::saveToDedicatedTables:
          // When updating an existing revision, keep the existing records if the
          // field values did not change.
          if (!$entity->isNewRevision() && $original && !$this->hasFieldValueChanged($field_definition, $entity, $original)) {
            continue;
          }
    
  4. At this stage $original refers to the default entity revision. Forward non-default revisions are updated in order, after their predecessors.
  5. Since the revision $original has already been updated in the batch to our new value $entity->my_field === $original->my_field, so the saving is skipped.
  6. My revision is now stuck with a field value that can never be updated.

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Consider use of Media video in Umami demo

$
0
0

Problem/Motivation

Now media is available, we should consider how to implement its video handling capabilities in Umami.

Proposed resolution

Decide if and how to showcase this. Should we include video recipes? Or video versions of articles? Should they be mandatory, or just available on a subset?

Remaining tasks

All the things.

User interface changes

TBD

API changes

None

Data model changes

None


Update the Content Moderation module description

$
0
0

Problem/Motivation

The module description could be extended a bit to give more detail to explain that other modules are needed to use this.

Proposed resolution

Reword the description to something like "Provides publication states that can be used by other modules to moderate content."

Remaining tasks

None.

User interface changes

This is a UI text change.

API changes

None.

Data model changes

None.

Uncaught Error: Call to undefined function cache_get()

$
0
0

Stack trace:
#0 /var/www/html/****/includes/module.inc(954): module_implements('system_theme_in...')
#1 /var/www/html/****/modules/system/system.module(2511): module_invoke_all('system_theme_in...')
#2 /var/www/html/****/includes/theme.inc(798): _system_rebuild_theme_data()
#3 /var/www/html/****/includes/theme.maintenance.inc(57): list_themes()
#4 /var/www/html/****/includes/bootstrap.inc(2881): _drupal_maintenance_theme()
#5 /var/www/html/****/includes/errors.inc(179): drupal_maintenance_theme()
#6 /var/www/html/****/includes/bootstrap.inc(2609): _drupal_log_error(Array, true)
#7 [internal function]: _drupal_exception_handler(Object(Error))
#8 {main}
thrown in /var/www/html/****/includes/module.inc on line 754

This is what I am getting when I am trying to use drush. Please guide me to get it done.

log out after creating node if use smartphone to create node

$
0
0

When users use laptop to create content from content type, which I made, it is working perfectly but when users want to create content from their smartphones website going to log out and access denied message is coming out. In that content type I use place to upload photos. Actually I can not figure out where this error happening. It is already the website company is using and need urgent help pls. Thank you beforehand

FILE_EXISTS_RENAME in "file_save_data" sometime doesn't rename the existing file name and throws error for duplicate entry in "file_managed" entry

$
0
0

Hi There,

I have a lot of different images with the same name having different paths. I'm uploading them using file_save_data function using FILE_EXISTS_RENAME for renaming existing image with the same name.
I'm processing file through CRON, first time renaming of file works perfect but when I process again then renaming doesn't continue after the last renaming number that is attached at the end of the file. It throws an error like "file name with key 'example_1.jpg' already exists for field 'URI'".

Can you please help me out with the issue like what is the problem actually.

Database::getConnection / Database::Connection to failover connections

$
0
0

With the presence of Galera and other synchronous replication database technologies it would be useful to support multiple database connections in Drupal. These synchronous database provide the ability for multiple masters to be active at once.

Extending the value of the $databases[$key][$target] to allow an array of database definitions would facilitate this easily for system administrators (and module developers(?)).

$databases = array();
$databases['default']['default'] = array(
  "server1" => array(
    // Drupal's DB credentials here.
  ),
  "server2" => array(
    // Drupal's DB credentials here.
  )
};

The Drupal South talk that showed multimaster is possible https://drupalsouth2014.drupal.org.nz/sessions/coding-development/scalin... (if fact this was done by UQ: https://drupalsouth2014.drupal.org.nz/sessions/coding-development/case-s... ).

Viewing all 294734 articles
Browse latest View live


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>