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

Replace the schema example

June 2, 2017, 2:58 am
$
0
0

The Schema API page shows the code to define the database schema for the node table, but node_schema() doesn't define any node table anymore.
The example should be replaced with one still used in Drupal core code.

↧
Search

Solr Search

October 13, 2017, 1:18 pm
$
0
0

We have migrated to Drupal 7 which caused some issues to Solr 1.4 (before migration).
I have now installed Solr 4.3.2 and integrated to Drupal site as per the below guidelines.
https://www.lullabot.com/articles/installing-solr-for-use-with-drupal

I started indexing in Drupal site. But the indexing is stuck at 33% and I don't see any errors in logs.

Since that is happening in our live site too, I need to first disable Solr search so that at least default search will work.
Secondly, I am working on fixing this issue in our back up site. Can someone help me with these issues.
Thank You in advance.

↧
↧

[meta] Migrations from Drupal 8 to Drupal 8 and Drupal 8 to Drupal 9

November 3, 2015, 9:00 am
$
0
0

Problem/Motivation

We will eventually need to migrate Drupal 8 to Drupal 9 (and possibly Drupal 10).

Also while it's less common, there are use-cases for migrating Drupal 8 to Drupal 8 - things like migrating a multi-site to domain module.

Proposed resolution

Add Drupal 8 source plugins, and test coverage for an 8-8 migration.

This will provide the basis for the 8-9 migration path, since these would only change to due to changes in the migrate API in 9.x

If we add this before opening 9.x then we have the potential to keep 9.x in a 100% shippable state with support for 6/7/8-9 migration paths (even if we might move the 6.x sources to contrib at that point).

This is a much lower priority than 6.x/7.x sources, so marking postponed.

Remaining tasks

User interface changes

API changes

Data model changes

↧

Support deprecation testing for contributed modules on Drupal.org

September 25, 2018, 2:09 am
$
0
0

Problem/Motivation

Drupal core benefits from proper deprecation testing use @trigger_error(... - see https://www.drupal.org/core/deprecation.

Contributed modules also want to leverage the same system for testing to prove they are up-to-date with the latest API changes and to handle deprecating their own code. However this is tricky because a contributed module typically has to support the current patch branch, the future development branch and the old patch branch which is still security supported. As of 25th Sept 2018 that's 8.5.x, 8.6.x and 8.7.x. If core adds a new deprecation in 8.6.x and new code to support that deprecation (eg. #2996789: Deprecate Drupal\field\Tests\EntityReference\EntityReferenceTestTrait) then it is not possible to have passing tests on all three branches. In 2996789 the contrib maintainers argue for the deprecation to be removed from 8.6.x but this only pushes the problem down the line and they'll still have fails in 8.7.x.

Possible solutions

  1. Only add deprecation messages to core at a later date. I.e introduce the new code path in 8.6.x and only commit the deprecation @trigger_error() in 8.8.x. That way when 8.8.x starts to trigger the deprecation the 8.7.x (patch) and 8.6.x (security) branches have the code and everyone can easily move. @alexpott thinks this is a terrible solution because it means new usages of deprecated code will be added to core and we will forget to add deprecations.
  2. We could do solution 1 and mitigate @alexpott's concerns by opening a future deprecation branch (eg. 8.8.x) to commit deprecation messages to but that will increase complexity for everyone working on core especially core maintainer. And @alexpott still thinks this is not a good solution
  3. Contrib needs a way to say ignore deprecations when testing against these branches. So for example a contrib module could disable deprecation testing against the patch and security branch (now 8.5.x and 8.6.x) but enable it against the future dev branch (8.7.x). That way the contrib module can prove they work against the currently support Drupal branches but also be aware of future work coming up. Additionally it would be great to be test any matrix the contrib author would like. I.e. to have testing with and without deprecations against the future dev branch.

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

↧

[META] Drupal 8 core must not use any deprecated code, must be enforced by automated testing

October 17, 2018, 6:57 am
↧
↧

[meta] Core should not trigger deprecated code except in tests and during updates

April 6, 2018, 12:30 pm
$
0
0

Problem/Motivation

#2870194: Ensure that process-isolated tests can use Symfony's PHPunit bridge to catch usages of deprecated code added the ability to test deprecated code. In order to get that done we add to add \Drupal\Tests\Listeners\DeprecationListenerTrait::getSkippedDeprecations() because core is exercising lots of deprecated code. This is all technical debt that we need to clear up. This issue is going to coordinate all the issues that need to be filed in order to stop using deprecated code.

The @todo list:

Proposed resolution

Ensure each skipped deprecation has an issue to work on.

Remaining tasks

Create all the necessary issues

User interface changes

None

API changes

None

Data model changes

None

↧

[meta] Remove calls to @deprecated and "backwards compatibility" procedural functions from core

September 19, 2013, 8:04 am
$
0
0

@todo - write a nice explanation of the reasons (for now, @see comment #5) we should do this with examples on howto (for now, @see http://php.net/manual/en/language.namespaces.php, http://php.net/manual/en/language.namespaces.importing.php)

\Drupal\Component\Utility\Json

- #2093161: Remove all calls to drupal_json_encode() in favour of \Drupal\Component\Utility\Json::encode()
- #2093173: Remove all calls to drupal_json_decode(), use \Drupal\Component\Utility\Json::decode()

\Drupal\Component\Utility\MapArray

- #2093179: Remove and deprecate calls to drupal_map_assoc(), use \Drupal\Component\Utility\MapArray::copyValuesToKeys()

\Drupal\Component\Utility\String

- #2089331: [meta] Replace calls to check_plain() with Drupal\Component\Utility\String::checkPlain()

\Drupal\Component\Utility\Unicode

- drupal_convert_to_utf8
- drupal_truncate_bytes (done!)
- truncate_utf8
- mime_header_encode
- mime_header_decode
- decode_entities
- drupal_strlen
- drupal_strtoupper
- drupal_strtolower
- drupal_ucfirst
- drupal_substr

\Drupal\Component\Utility\Xss

- #2089433: Remove uses of deprecated XSS filter functions

\Drupal\Component\Utility\Url

- #2089327: Remove / deprecate calls to drupal_strip_dangerous_protocols() use \Drupal\Component\Utility\Url::stripDangerousProtocols()

\Drupal\Core\Render - #2109793: Convert element_* methods in common.inc to a class

- #2181507: Remove the deprecated usages of element_* methods
- #2393329: Replace all drupal_render calls with the service, and inject it, if possible.

Related issues

- #2042165: Add a 'deprecated' module that includes deprecated functions only when enabled

↧

Add support for Token and plural in Views Global result summary plugin

June 21, 2017, 9:54 pm
$
0
0

Hello team,

I recently used views to build my search page, and added a Global Result summary block in the header. I see few tokens are available. I used the token "@total" along with I need to display "item" OR "items" based on number of results. I could not find any way of doing it via the UI.
I had to do alter and make the text plural.
I was told that, tokens can be help here.

Can you please look into this tiny thing, where it support plural, and also support its translation.

Happy to provide any further info and help.

Thanks.

↧
Search

Use time service in KeyValueDatabaseExpirableFactory and DatabaseStorageExpirable classes

December 20, 2017, 10:48 am
$
0
0

Problem/Motivation

REQUEST_TIME constant is marked as deprecated and a time service was added to 8.3.x in #2717207: Add a time service to provide consistent interaction with time()/microtime() and superglobals.
See parent issue #2902895: [meta] replace uses of REQUEST_TIME and time() with time service for full description.
Here is the change record also.

Proposed resolution

All occurrence in code should be updated to remove deprecated uses of REQUEST_TIME, time() and microtime().

Remaining tasks

None

User interface changes

None

API changes

None

Data model changes

None

↧
↧

Fatal error on config form with translation enabled when config is missing

November 21, 2017, 7:37 am
$
0
0

Steps to reproduce:
* Create a new config form that modifies an custom configuration
* Create a route for the config form
* Make sure the custom_config doesn't exist in the active configuration
* Create a *.config_translation.yml for the custom configuration
* Go to the route for the config form

A fatal error occurs:
TypeError: Argument 2 passed to Drupal\Core\Config\TypedConfigManager::createFromNameAndData() must be of the type array, boolean given, called in /core/lib/Drupal/Core/Config/TypedConfigManager.php on line 78 in Drupal\Core\Config\TypedConfigManager->createFromNameAndData() (line 391 of core/lib/Drupal/Core/Config/TypedConfigManager.php).

This happens with Drupal 8.4.2 because the system tries to read the configuration, but since the data doesn't exist it returns FALSE, hence the error.

↧

preg_replace of adjacent search terms ignores whitespace

October 17, 2018, 6:55 am
$
0
0

The search terms are surrounded with <strong> tags, but in the case of search terms being adjacent in the resulting content, the whitespace separating the search terms is not part of the text content anymore because of how HTML works.

So with search terms "Flu Shots" the text

Flu Shots available at the following locations

Becomes

<strong>Flu</strong> <strong>Shots</strong>" available at the following locations"

and the space is not shown in the results.

Screen capture

↧

Theme hook in custom module not found after clear cache

October 17, 2018, 7:27 am
$
0
0

i have this simple controller:

class PageController extends ControllerBase {
  
    public function registerPage() {
		
		return [
			'#theme' => 'gey_user_agent__register_page',
			'#content' => array(),
			'#attributes' => [],
			'#cache' => array(
					'max-age' => 0
			)
    	];
	}
	
}

and the theme hook

function gey_user_agent_theme($existing, $type, $theme, $path) {
    return array(
        'gey_user_agent__register_page' => array(
            'variables' => array('content' => NULL),
        ),
    );
}

when i install the module i have no problem. i can see the content of the template.
after clear cache i get this error.

Theme hook Theme hook gey_user_agent not found.

After reinstall works fine till i clear the cache.

Which is the problem?

↧

InvalidArgumentException: "$string ("") must be a string." using database query

October 13, 2018, 4:17 pm
$
0
0

Steps to reproduce the bug:

- Create query string with WHERE clause containing LIKE.
- The argument passed to the LIKE condition is a named placeholder.
- The LIKE condition contains the % wildcard leading and trailing the value.
- The value is escaped with $injected_database->escapeLike() (NOTE: The InvalidArgumentException is still thrown if I don't escape the value)
- The value is a string of three numbers including: "000", "005", "123"

What behaviour I'm expecting:

- $injected_database->query($queryString, [':param' => '%' . $injected_database->escapeLike($search) . '%']);
will replace all instances in $queryString where ':param' exists with: '%123%' assuming $search = "123";

What happened instead:

Uncaught PHP Exception InvalidArgumentException: "$string ("") must be a string." at /core/lib/Drupal/Core/StringTranslation/TranslatableMarkup.php line 132

↧
↧

Some docblock fixes for PHP type 'stdClass'

November 4, 2015, 7:43 am
$
0
0

The D8 documentation standards at https://www.drupal.org/node/1354 state that for the built-in PHP data type stdClass the string 'object' should be used in docblocks rather than 'stdClass'. Attached is a patch correcting the only occurrence that currently exists within core.

↧

Unable to create new draft for content translation even if the path alias does not change

September 20, 2018, 1:47 am
$
0
0

Report based on #2930599: Unable to save a translation if the path alias changes (which is 'works as designed' imho).

Problem/Motivation

User can't add new draft for a content translation of a node if the path alias of the latest published entity (original language) is different from the path alias of the new translation draft's form.

Steps to reproduce

Setup

  1. (as an administrator user, suggested install profile: standard)
  2. Enable node, content_moderation, content_translation and path modules.
  3. Add an another language.
  4. Create a node type, add a workflow to it and make it translatable. Use the defaults settings of the content translation form.
  5. Create a node with in the default language with path alias. Publish it.
  6. Create a translation for the node with a translated path alias which is different from the one the default node has. Publish this translation as well.

Scenario 1

  1. Try to add a new draft for the translation while not changing the path alias.
  2. Expected: new draft is successfully saved while alias of the published translations remain the same.
  3. What happens: PathAliasConstraintValidator returns a validation error You can only change the URL alias for the published version of this content.

Scenario 2

  1. Now try to add a new draft for the translation while changing the path alias to the one what the original published entity revision has (original means the original language).
  2. Expected: Validation error.
  3. What happens: New translation draft successfully saved, and the alias of the published (default) translation revision changes to the one we just filled in.

Proposed resolution

Extend logic of PathAliasConstraintValidator to check for the default revision of the current entity language, and not the original entity.

Remaining tasks

Copy my patch from #2930599: Unable to save a translation if the path alias changes here.
Extend it with a test for Scenario 2
Get a review.

User interface changes

Nothing.

API changes

Nothing.

Data model changes

Nothing.

↧
Search

Data model problems with Vocabulary hierarchy

March 30, 2018, 9:32 am
$
0
0

There is a data model issue. Taxonomy terms are content, Vocabularies are config. Changing the taxonomy term content can change the config This is wrong. If the vocabulary hierarchy is indeed content, it should be stored somewhere else. The Vocabulary hierarchy field and the taxonomy hierarchy table are two different things, don't confuse them. This is about Vocabulary.hierarchy, which is just used by the UI.

As a User Interface configuration field, there is a also UI issue. If you configure a vocabulary to be hierarchical and the user removes all child terms, making the hierarchy flat, this changes the configuration from hierarchical to flat. Why does user content override the site builder's configuration? Further, if the user makes such a change, converting the vocabulary from hierarchical to flat, they can no longer add hierarchical terms on the taxonomy edit page, they can only do so on the overviews page.

I believe that Vocabulary.hierarchy is only used by the UI:

* If it's set to 0 (disabled), it's used on the overview page to not allow re-ordering. In our case, if it's set to 0, then the UI prevents re-ordering, and our change should never be called.
* If it's set to multiple, the term edit page displays related terms differently.

Our options are:

1. Treat the Vocabulary hierarchy as configuration only. Site builders can set this. Data changes do not change the hierarchy setting.
2. Add a vocabulary content entity that stores the configuration.
3. Remove the hierarchy property from vocabularies and compute it at runtime when needed.

I think (1) is the right option.

The patch from #4 implements option 3.

↧

Add a composer script method to Drupal\\Core\\Composer\\Composer::vendorTestCodeCleanup

September 11, 2018, 9:22 am
$
0
0

Problem/Motivation

Drupal\Core\Composer\Composer::vendorTestCodeCleanup() needs to be able to run on the whole install and not just one package at a time. Refactoring that to allow for post-create-project hooks would be useful.

This is to support #2990257: Determine how to handle composer scripts in drupal/drupal and be able to perform the vendor test cleanup once the library which supports it is available, which in turn supports creating the drupal/drupal-project-legacy project template in #2982680: Add composer-ready project templates to Drupal core.

Regardless of how #2990257: Determine how to handle composer scripts in drupal/drupal is implemented, we will likely need to be able to clean up the vendor directory in one step at the end of the installation process, since the library will have become available and autoloadable by that point.

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

↧
↧

Core oembed support can't parse soundcloud XML

June 28, 2018, 6:47 am
$
0
0

Problem/Motivation

Steps to reproduce:

Add this to a custom module:

function mymodule_media_source_info_alter(&$sources) {
  $sources['audio_oembed'] = [
    'id' => 'audio_oembed',
    'label' => t('Remote audio'),
    'description' => t('Use audio from remote sources.'),
    'allowed_field_types' => ['string'],
    'default_thumbnail_filename' => 'no-thumbnail.png',
    'providers' => ['SoundCloud'],
    'class' => 'Drupal\media\Plugin\media\Source\OEmbed',
  ];
}

Set up a media type using the source.

When you try to save a new media item pointing to soundcloud, you get the following error:

"The provided URL does not represent a valid oEmbed resource."

This is because soundcloud specifies type float for their oembed version, and Symfony's xml parser returns an array for floats.

Proposed resolution

Patch attached which makes it work, but not sure what the best solution is here.

Remaining tasks

User interface changes

API changes

Data model changes

↧

Provide inline_template tag within Twig that inlines a template for usage with a render array

July 21, 2013, 6:22 pm
$
0
0

From Twig call:

- Add inline_template function to support e.g. #post_render for render arrays with custom one-shot template.

Problem/Motivation

Drillability for Twig is important, but the scope was not clear and how to support #post_render / #theme_wrappers / drupal_render integration.

Proposed resolution

This issue frees drillability to only allow to drill-down by splitting the use case of supporting #post_render / #theme_wrappers and the rest of drupal_render into an inline_template twig tag, by replacing the actual engine render call with a method called on a twig template class.

'#render_function' => array($template, 'magicMethodName'),

Example:

{{ link }}

vs.

{% inline_template link %}
<a href="{{ attributes.href }}">{{ text }}</a>
{% endinline_template %}

Remaining tasks

* Move the #type specific things to a follow-up
** Create the follow-up and make clear what the problems are.

* Fix syntax and make it possible to specify an identifier and an expression, if the expression is a render array, hide and show will work (remove hard-coded "link")
** Like: {% inline_template "link" link %}
** Or like: {% inline_template "link" { '#type': 'link', '#href': 'node', '#title': 'hi' } %}

* Clean-up, docs and get this committed

Done tasks


* Create proof-of-concept by extending macros. This inline templates are added as macros, but internally use a different Twig_Node to call drupal_render instead.
* Extend theme() to allow setting the $render_function used to render the template within the "render variables".

User interface changes

* None.

API changes

* Adding of a new twig tag.

#2008450: Provide for a drillable variable structure in Twig templates

↧

Run composer install during testing again to make sure that all dependencies are up-to-date

October 17, 2018, 9:08 am
$
0
0

Problem/Motivation

If core changes it's composer.lock and we test against PHP 5 these new dependencies are not picked up. This means we're not testing what we think we're testing. It works for PHP7 because in order to run against PHP7 we do a composer install to upgrade PHPUnit - which happens to also do the necessary changes.

See:
https://dispatcher.drupalci.org/job/drupal_patches/72407/consoleFull - this test should have tested against Symfony v3.4.15 but it did not. Unlike https://dispatcher.drupalci.org/job/drupal_patches/72468/consoleFull which did.

This is a critical issue because we are not testing what we think we are testing.

Proposed resolution

Add an interim fix to patch drupalci.yml to do a composer re-install. If there are no changes this will be a noop. This will be fixed properly in #3005743: update_dependencies plugin is not triggering when core modifies core/composer.json

Remaining tasks

User interface changes

None

API changes

None

Data model changes

None

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