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

"cannot call methods on dialog prior to initialization" logged when resizing after closing a modal

May 23, 2016, 8:22 am
$
0
0

When using Drupal modal dialog system there is an error that are log to the console of the browser :

Uncaught Error: cannot call methods on dialog prior to initialization; attempted to call method 'option'

This problem is not blocking, is just annoying.

Steps to reproduce

  • Go to a page containing a modal dialog like /admin/structure/block
  • Click on the link opening the modal (on /admin/structure/block page click on the "Place block" button)
  • Close the modal
  • Resize the page

Technical steps

  • Resizing the window call the Drupal.displace function (misc/displace.js line 56)
  • displace trigger a drupalViewportOffsetChange event (line 81)
  • This event trigger the resetSize function for dialog (misc/dialog/dialog.position.js line 34)
  • Which try to call the dialog method (but dialog has been closed)

Proposed solution

See patch

↧
Search

Patch testing issue

April 15, 2013, 2:55 am
$
0
0

THIS ISSUE IS NOT FOR REVIEW.
This is a place holder to:
1. Test patches that are passing in local and not in d.o.
2. Demo d.o workflow, review patch, using d.o tools (like dreditor).

FAQs

Can I use this issue to test my patch?

Of course you can. Just remember, this issue is to test patches so that, your main issue would be clean. You still need to use your main issue to show progress.

↧
↧

Datetime's Configuration "#date_time_format" is not working

January 5, 2017, 5:25 am
$
0
0

Below configuration of "#date_time_format" for form element 'datetime' is not working :
$form['custom-module-datetime'] = array(
'#type' => 'datetime',
'#date_date_format' => 'm/d/Y',
'#date_time_format' => 'H:i A',
'#default_value' => DrupalDateTime::createFromTimestamp(time()),
);

Even if custom "date_time_format" is provided, Datetime module is setting the format to default one i.e. DateFormat::load('html_time')->getPattern(); (Datetime.php file of Datetime module in core).

↧

For Drupal migration, identify the source module

September 16, 2015, 1:52 pm
$
0
0

The migrate_upgrade UI is now providing a confirmation page, showing the administrator performing the upgrade what modules are being upgraded from their legacy sites (and what modules are not). There is not currently an automated way to get this information - the closest thing is the source_provider annotation on the source plugin, but this doesn't help us with configuration-only migrations. My suggestion is adding a module key to the source plugin config for the Drupal migrations.

↧

Move old CCK assertions into MigrateNodeTest

August 25, 2015, 3:51 pm
$
0
0

In #2538000: The d6_node plugin should fetch CCK field values, the d6_cck_field_values and d6_cck_field_revision migrations, which are rendered obsolete by the new builder plugins, were removed. They were also the final blockers to removing load plugins.

Their accompanying tests (MigrateCckFieldValuesTest and MigrateCckFieldRevisionTest) were removed as well. But they contained useful assertions which should be merged into the D6 MigrateNodeTest, so that we don't outright lose that test coverage. This will require the tests to be builder-aware, which is addressed in #2549013: Remove load plugins.

Once that one lands, the assertions from MigrateCckFieldValuesTest and MigrateCckFieldRevisionTest -- as found in the final patch from #2538000: The d6_node plugin should fetch CCK field values -- should be moved into MigrateNodeTest. The assertions from MigrateCckFieldValuesTest have been moved to the patch in #3.

Remaining tasks

1. Reroll the patch in #3.
2. Add the assertions from MigrateCckFieldRevisionTest to the patch. Here are the assertions.

  /**
   * Test CCK revision migration from Drupal 6 to 8.
   */
  public function testCckFieldRevision() {
    $node = \Drupal::entityManager()->getStorage('node')->loadRevision(2);
    $this->assertIdentical('1', $node->id(), 'Node 1 loaded.');
    $this->assertIdentical('2', $node->getRevisionId(), 'Node 1 revision 2loaded.');
  }

3. Test
4. Fix errors until tests pass.

↧
↧

Fixture data is wrong for MigrateMenuSettingsTest

September 3, 2016, 5:01 am
$
0
0

Problem/Motivation

The D7 variable menu_override_parent_selector must be TRUE in the drupal7.php fixtures so that it makes sense for MigrateMenuSettingsTest.

Proposed resolution

Make the menu_override_parent_selector correct again as it was in #2353763: Variable to config: menu.settings [d7]

Remaining tasks

Patch.

User interface changes

None.

API changes

None.

Data model changes

None.

↧

Upload-field not migrated if not explicitly enabled on D6.

November 21, 2016, 4:12 am
$
0
0

Problem/Motivation

On a D6 site with the upload module enabled, file attachments are considered enabled by default if the upload_[node_type] is not set. Ran into an issue with a custom D6 to D8 migration, where one content type had file attachments enabled on the D6 instance, but the upload field was missing after migration on the D8 site (two other content types with file attachments enabled did have the upload-field on D8 after migration.)

Relevant code snippet in D6's upload module:

function upload_form_alter(&$form, $form_state, $form_id) {
  if ($form_id == 'node_type_form'&& isset($form['identity']['type'])) {
    $form['workflow']['upload'] = array('#type' => 'radios','#title' => t('Attachments'),'#default_value' => variable_get('upload_'. $form['#node_type']->type, 1),'#options' => array(t('Disabled'), t('Enabled')),
    );
  }

  if (isset($form['type']) && isset($form['#node'])) {
    $node = $form['#node'];
    if ($form['type']['#value'] .'_node_form' == $form_id && variable_get("upload_$node->type", TRUE)) {
      // Attachments fieldset
      $form['attachments'] = array(
...

Proposed resolution

Since the "File attachments" field(set) is showing up on the original D6 site when the "upload_[type]" variable is not explicitly set, that content type should be considered as having file attachments enabled. Migrate the upload-field for all content types where it is either explicitly enabled, or where the variable is not set.

Remaining tasks

- Review
- Commit

User interface changes

None

API changes

None

Data model changes

None

↧

Unable to migrate D7 User cck fields

February 23, 2016, 4:03 am
$
0
0

Problem/Motivation

The D7 User migration plugin fails to migrate cck fields (e.g. file fields and taxonomy term reference fields) because in the field database table some of the D8 fields (e.g. field_FIELD_NAME_target_id) have different names to D7 (e.g. field_FIELD_NAME_tid) and so require a custom transform function.

Proposed resolution

Use the cck plugin manager in a similar manner to the D7 Node migration plugin because that is able to handle cck fields (e.g. file fields and taxonomy term reference fields).

Remaining tasks

Review and commit.

User interface changes

API changes

Data model changes

↧
Search

Add documentation to download process plugin

November 29, 2016, 6:38 pm
$
0
0

Add API documentation to the Download process plugin.

↧
↧

Reduce method and control structure length/complexity in Migrate UI

March 2, 2016, 3:48 pm
$
0
0

Problem/Motivation

From @tim.plunkett's review in #2281691: User interface for migration-based upgrades:

  1. +++ b/core/modules/drupal_upgrade/src/Form/MigrateUpgradeForm.php
@@ -0,0 +1,1196 @@
+    else {
+      $table_data = [];
+      $system_data = [];
+      foreach ($form_state->get('migration') as $migration) {

    This is a very large else block. Can this function be rewritten to avoid that, or broken into smaller methods?

  2. +++ b/core/modules/drupal_upgrade/src/MigrateUpgradeRunBatch.php
@@ -0,0 +1,358 @@
+  public static function run($initial_ids, $operation, &$context) {

    This is another very large method that does a lot. Any way to break it up?

Proposed resolution

Refactor the code to reduce complexity.

Remaining tasks

User interface changes

API changes

Data model changes

↧

FormatDate process plugin

October 19, 2016, 8:42 am
$
0
0

Problem/Motivation

If you import from CSV, XML, JSON (non-Drupal sources), it is fairly common to have dates formatted in lots of different ways. Let's provide a mechanism to format them to the required formats provided by Drupal.

Proposed resolution

Code. Do it.
Write tests.

Remaining tasks

Reviews

User interface changes

API changes

Data model changes

↧

Fix path alias migration of translated nodes [D6]

November 14, 2016, 5:33 pm
$
0
0

Problem/Motivation

Sub-issue for #2746527: [META] Handle data related to D6 translations with different IDs.

When migrating path aliases of translated nodes, some aliases will point to non-existent nodes since source and translations are stored in the same node.

If in D6 we have node/1 as the source in English and node/2 as the French translation, in D8 we will only have node/1. If we had an alias for node/2, it won't work anymore.

Proposed resolution

When migrating path aliases, use the migration process plugin to get the translation source nid and correct the translation path aliases.

Remaining tasks

Write a patch. Write a test. Review.

User interface changes

None.

API changes

None.

Data model changes

None.

↧

MigrationPluginManager::getDefinitions() blows up in node derivers

November 23, 2016, 8:58 am
$
0
0

Problem/Motivation

Calling MigrationPluginManager::getDefinitions() when the migrate_drupal module is enabled and no connection is defined for the drupal migrations, we get ConnectionNotDefinedException from the node derivers, and thus get no migrations back (even the ones that are fine). This happens because the derivers execute the node_type source plugin - with no explicit database connection configured, SqlBase attempts to use a connection named 'migrate' and if no such connection exists ConnectionNotDefinedException is thrown.

Proposed resolution

When SqlBase falls back to attempting the 'migrate' connection, the lack of such a connection should be treated as a RequirementsException rather than allowing ConnectionNotDefinedException to propagate. SqlBase should also implement RequirementsInterface, which should throw RequirementsException in this instance. And, the node derivers should check the requirements on the node_type migration and return without deriving any node migrations when the requirements are not met.

Remaining tasks

Extract the relevant parts of the patch in #2700693: [meta] Make MigratePluginManager::getDefinitions() work cleanly with migrate_drupal enabled.

User interface changes

N/A

API changes

getDatabase() will now throw RequirementsException in the absence of a configured database connection.

SqlBase and all derived source plugins will implement RequirementsInterface, and thus checkRequirements() will now be available on all such source plugins.

Data model changes

N/A

↧
↧

Cache tags for content revisions and contextual filters

January 5, 2017, 7:56 pm
$
0
0

While working on #1863906: Replace content revision table with a view I ended to the conclusion that in some way the cache tags for views that lists content revisions based on node contextual filters are not properly invalidated.

After checking the implementation made on #2318377: Determine whether a view is cacheable and its required contexts, store this i/t config entity it seems when using node as contextual filters, cache tags are set to 'cache.context.url' which in the case on content revisions could not be enough.

What should be the right approach to fix this issue. Should #1863906 add an specific cache context for views that lists revisions and use node as contextual filters?

↧

Replace content revision table with a view

December 11, 2012, 8:18 am
↧
Search

Add Views Entity Reference Filter to core

May 2, 2016, 9:51 am
$
0
0

Problem/Motivation

We have \Drupal\taxonomy\Plugin\views\filter\TaxonomyIndexTid in core to show taxonomy ER field as autocomplete or select list but for other ER fields there is no filter plugin.

Proposed resolution

Move https://www.drupal.org/project/verf to core

This module provides a user-friendly Views filter for configurable entity reference fields. Instead of having to enter entity IDs manually, users can select the labels of the entities they want to filter on.

Remaining tasks

Fix #2720953: Security issue: Information disclosure while porting this module to core.

User interface changes

ER field can expose autocomplete or select list filter in the Views.

API changes

None

Data model changes

None

↧

Long Twig cache directories can cause failures on some filesystems

November 2, 2015, 2:59 pm
$
0
0

Problem/Motivation

A D8 install can easily generate extremely lengthy file/directory names when caching Twig templates.

On some scenarios, the maximum length for a path might be limited by the OS:

  • Windows has a maximum path length of 260 characters. Can read more here.
  • If you are in Linux and have the filesystem where you have the site mounted using eCryptfs and its configured to encrypt filenames as well as the file content you will experience this same issue. You can read a little about this limitation here.

To reproduce this issue on Windows, add the following to settings.php.

$settings['file_public_path'] = 'sites/default/files/0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-01'; // That's a 255-char dir name.

Proposed resolution

Update as of #144 going with option #3

Option #3: Trigger a requirement error on windows if the Drupal root is deeper than 100 characters. Use our existing base64 hash and hmac functions so the hashes are half as long to start. Truncate the human-readable template name portion and hash portion of the to a maximum length so the directory names can never be longer than 51 characters. The cache file name itself has already been shortened to 47 characters using the bas64 hmac in the split-off child issue #2830596: MTimeProtectedFastFileStorage::getFullPath() creates really long filenames unnecessarily

Update: as of #39, options #2 is the preferred solution.

Option #1: Use the Unicode path prefix (\\?\) on Windows to avoid the 260 character limit (pushes the limit to around 32k which is well above Linux's limit of 4k characters). Unfortunately, PHP's support of these pathnames is limited. (see #16) which would require a much more disruptive fix.

Option #2: Use shorter hashes while retaining the "uniqueness" of these directory and file names. However, the filename hash contains the filemtime() of the containing directory. If, for example, file uploads were compromised and malicious code added to a cached Twig template, the containing directory's filemtime would change and the hash would not match. Using shorter hashes could potentially increase the risk of a compromised file still passing the hash test. (Security review requested).

Also, option #2 does not solve the underlying problem, but hopefully gives us some breathing room. Currently, there are two 64-character hashes in each cached Twig template.

Remaining tasks

As of #12:

  1. not needed since we're using option #2: FileStorage::unlink does not work with the Unicode prefix
  2. Needs security review to ensure that shortened hashs still give enough "uniqueness" for MTimeProtectedFastFileStorage
  3. Needs tests to assert that generated files do no exceed a (somewhat arbitrary) limit
  4. Done: Add hook_requirements to warn users when installing Drupal on Windows with a long path name.

User interface changes

Adds a new warning when installing Drupal on Windows at a path > 100 characters.

API changes

With option #2, none.

Data model changes

None.

↧
↧

Sorting on Unformatted View Style

January 5, 2017, 11:06 pm
$
0
0

Hi All,

I have created a list page using views with unformatted style.Now I want to implement sorting like Table sorting in the Unformatted style. Like

Sort by

Title↑↓ Posted Date↑↓

I want the sorting just like above example.Please help me that how I can implement the sorting in this way in Unformatted style.

Thanks in Advance.

↧

Allow changing the 'Send message' contact form string and optionally hiding the preview button

March 17, 2016, 9:14 am
$
0
0

Problem/Motivation

Submit message button is hardcoded but there are other uses for contact forms.
Preview button always displays but sometimes you don't want it.

Proposed resolution

Add new properties to ContactForm entity - button text and show preview
Add these to the contact form schema
Add new fields to edit form to set the values
Alter the message form to use these new values to set the button text and preview visibility
Test coverage

Remaining tasks

All of the above
You can borrow elements from contact storage module

User interface changes

New form options in contact form edit form

API changes

None

Data model changes

None

Original report

We would like to request more options to edit the buttons through the Contact Form UI in Drupal 8:

Request #1: We would like to change the text of the contact form's submit button from "Send Message" to something else within the UI since we'd hope to use this module for several diverse small forms on our site. For instance, we have one form that's a Demo Download so "Get Download" makes more sense.

Request #2: We would like to either hide or remove the preview button within the UI as it's not always needed on our forms.

↧

translation main menu access denied error

January 6, 2017, 1:00 am
$
0
0

When I am trying to translate the menu item under main menu e.g "About US" its show the message like You are not authorised to access this page. I have checked all the permissions to the admin account. And also select the multilingual option "translate and localize" but same error occur. I don't know where i can troubleshoot this error.

↧
Viewing all 295427 articles
Browse latest View live
Search
<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>