Quantcast
Viewing all 295966 articles
Browse latest View live
↧

Remove drupal_static from BookManager

January 22, 2015, 7:52 pm
$
0
0

Problem/Motivation

drupal_static() will be deprecated in #2260187: Deprecate drupal_static() and drupal_static_reset().

Proposed resolution

Switch to class protected property.

Remaining tasks

None.

User interface changes

None.

API changes

None.

Data model changes

None.

Release notes snippet

N/A

Original report

Child of #1577902.

BookManager::bookSubtreeData
BookManager::bookTreeAllData
BookManager::doBookTreeBuild

have calls to drupal_static(). These should be replaced with protected properties.

↧
Search

[ignore] tedbow patch testing

June 5, 2018, 6:43 am
↧
↧

Deprecate drupal_static_reset() without @trigger_error()

March 2, 2019, 11:08 am
$
0
0

Problem/Motivation

We want to deprecate drupal_static() and drupal_static_reset(): #1577902: [META] Remove all usages of drupal_static() & drupal_static_reset()

However, for backwards compatibility, we have to turn drupal_static_reset() into a special case that does not call @trigger_error().

In general, code that calls drupal_static_reset() without calling drupal_static() is very likely needed for BC.

Examples of this include drupal_flush_all_caches() and \Drupal\Core\Test\FunctionalTestSetupTrait::prepareEnvironment().

Proposed resolution

Formally deprecate drupal_static_reset() without calling @trigger_error(), along with documentation explaining why we don't call it.

Find all these usages necessary for BC.

Add @todo and @see for these usages, pointing to the change record: https://www.drupal.org/node/2661204

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

↧

Deprecate drupal_static() and drupal_static_reset()

May 6, 2014, 1:25 pm
$
0
0

Problem/Motivation

drupal_static() should ideally be obsolete, but there are many procedural places in core that use them.

Other properly injected OO code needs to use drupal_static_reset() because of that, which leads to include-hell for tests.

Proposed resolution

Deprecate drupal_static() and drupal_static_reset(). Provide no replacement as using static variables is a bad design. Document that new code should not use drupal_static().

Remaining tasks

None.

User interface changes

None.

API changes

Both drupal_static() and drupal_static_reset() are now deprecated.

↧

[META] Remove all usages of drupal_static() & drupal_static_reset()

May 14, 2012, 6:45 am
$
0
0

Problem/Motivation

In #2260187: Deprecate drupal_static() and drupal_static_reset() we'll deprecate the drupal_static()& drupal_static_reset() procedural functions. However, in order to do so, we have to remove first all usages from Drupal core.

Proposed resolution

We cannot do all the removals in one step. Each usage it's an issue itself. So, this issues is a META to track the progress:

Child issues:

Remaining tasks

N/A

User interface changes

N/A

API changes

N/A

Data model changes

N/A

Release notes snippet

N/A

Original report

from comment #19 of #1567428: Active trail tests, in order to handle static variables in Drupal 8 we should convert every use of statics to instead be protected properties of proper objects. The result of this effort will be that we properly register objects into the Dependency Injection Container and perhaps do away with drupal_static() and drupal_static_reset().

↧
↧

[policy] Enforce PHP7 for Drupal 8.7.0

February 18, 2019, 6:49 pm
$
0
0

the policy summary is: how long Drupal8 can run on PHP5?
until 2019. december 4 (D8.6EOL)
until 2020. jun 3 (D8.7EOL)

I would like to point out that PHP 7 only changes are currently not allowed for Drupal 8.7, and I am starting to disagree with such decision.

https://groups.drupal.org/node/518200

no PHP 7-only changes will be made until the 8.8.x branch is opened

#2961861-19: Remove usage of WriteCheckSessionHandler

there is an idea of maintaining PHP 5.6 support in 8.7.x unless we really can't.

- This was not discussed in #2842431: [policy] Remove PHP 5.5, 5.6 support in Drupal 8.7
- This is extra work, making workaround on workarounds.
- Issues are postponed until D8.8, even they need to be solved now, creating workarounds again #2950132: Support PHPUnit 7 in Drupal 8
- This means Drupal will be fully supporting PHP7, only from year 2020. I see this as a barrier of innovation.
- We should motivate people to update their php, and not suggest to use php5 for another year.
- I do not think contrib will care about php5 that long.
- If someone still needs php5, why not just use D8.6? It will be supported until the end of the year, until D8.8. If an issue is backported to 8.6 then it is tested on php5, right? Or maybe not, at least the last commit for D8.6 was not tested on php5 according to the issue #3019333: If you translate the literal "inline blocks" to another language in the layout builder, it stops working.
but it should be anyway
#2917655-16: [policy] Decide on PHP 7.x support status

Drupal 8.6.x will continue to be tested on PHP 5.6 until support for that branch is dropped

- the date when PHP7 is enforced does not have to be with D8.7.0, but as I feel it must be before Christmas (before D8.8)

https://www.drupal.org/core/release-cycle-overview#current-development-c...

↧

Deprecate RDF module in favor of Schema.org-focused JSON embedded in the page

December 8, 2013, 9:39 am
$
0
0

As a maintainer of RDF module, I don't have much confidence that the module provides the reliability we need for Drupal 8. We don't have a solution for compound fields (such as addressfield). Not all core field formatters are tested, to say much less of contrib field formatters. And we have criticals that haven't seen any major movement in many months.

In the meantime, Google has announced that it will consume JSON that is embedded in pages using <script> tags, and other search engines have followed suit. As I outline in my companion blog post, this is preferable to HTML data formats (RDFa, microdata) for a number of reasons. The ones relevant to this issue are:

  1. It would mean we could use the same pipeline for REST’s serialization and HTML data
  2. It removes complexity from the field formatters and theme layer
  3. It makes it easier to replace the implementation from contrib

While this is a large change in terms of the description on the Drupal 8 box, I'm fairly certain it will actually require less work than getting our RDFa up to snuff and has a better chance of being reviewable by other people, which this work hasn't really been in the past.

↧

node/add page misses content types when menu links are moved or disabled

December 29, 2010, 10:32 am
$
0
0

Steps to reproduce:

  1. Go to admin/structure/menu/manage/navigation
  2. move both Article and Basic page (on a default install) out from under Add content
  3. The page will lie to you, claiming: "You have not created any content types yet. Go to the content type creation page to add a new content type."

Good news: If you move the entire Add content menu item with its children from navigation to, another menu, the node/add page still works...

Bad news: ...the node/add page still works but includes options only for any "Add {content_type}" sub-menu that its respective menu item was moved along with the parent Add content menu item. Any custom content types created after the move of the menu keep adding their respective "Add {content_type}" menu items under the Navigation menu. So, the effect caused is that people wonder why their custom content types don't get a "Add {content_type}" entry in the "Add content" page and a submenu under the "Add content" menu item.

Also, you can disable the Add content link in Navigation, its children still show up there and on node/add.

Bad news: If you disable a node/add/[content-type] menu link, it disappears from the node/add page too.

This is a regression from Drupal 6, as i remember disabling less important content types from the menu and still being able to access them on the node/add page.

↧
Search

It's very difficult to alter forms of inline (content blocks) placed via Layout Builder

January 25, 2019, 6:27 am
$
0
0

I was recently looking to modify the form for a content block entity that's placed as an inline block via Layout Builder.

This turns out to be quite difficult:

  • The outer most form is either \Drupal\layout_builder\Form\AddBlockForm or \Drupal\layout_builder\Form\UpdateBlockForm, so that's what needs to be form_altered()
  • Layout Builder's block form works similarly to core's \Drupal\block\BlockForm, in that it embeds configuration form for the block plugin inside of it. I guess this is called a "subform".
  • For inline blocks in layout builder, there's a block plugin class \Drupal\layout_builder\Plugin\Block\InlineBlock. The configuration form for this block plugin is created by building an entity form display for the content block entity that you're trying to create. It does this in a #process callback

Because the actual block content entity form is rendered in a #process callback, a developer that implements a form_alter for layout builder will have a bad time, since the form elements for the block content entity are not actually built yet. Here's what the form array looks like in the form_alter:

Image may be NSFW.
Clik here to view. form alter array

Instead, I believe the developer must alter the form to add their own #process callback. And it cannot be added to the outer form array because it's still too early there. It needs to be added to the block_form, after the processBlockForm callback is done.

I wonder if there's a way to improve the developer experience here.

↧
↧

Ellipsis and wordsafe options to TrimmedTextFormatter

April 10, 2018, 10:02 am
$
0
0

Hello,

I'd like to add a functionnality for the TextTrimmedFormatter to be able to add an ellipsis and / or word boundaries trim options.

Patch attached.

↧

Make service for field discovery for use in migrate entity derivers

March 9, 2018, 6:03 am
$
0
0

Problem/Motivation

In contrib (and even in core itself), there is a lot of boilerplate repeated when a migrate source deriver wants to add fields to an source migrate deriver for a fieldable entity. Let's make the code for discovering and adding fields generic and by creating a re-usable service. This will reduce the duplication of code copy/paste spread across all the derivers, not only in core but also in contrib.

Paragraphs and Commerce would use this. Node, user and taxonomy term in core could also.

Proposed resolution

Take a look at node source deriver, make a service and then implement it for node, user and taxonomy.

Remaining tasks

  1. Code it
  2. Run existing tests
  3. Commit it

User interface changes

API changes

Data model changes

↧

Split up simpletest into simpletest and testing_ui to enable easier decisions for Drupal 9

January 26, 2019, 9:18 am
$
0
0

Problem/Motivation

There are two potential removals possible in Drupal 9 in the context of simpletest:

Both decisions are sort of orthogonal as in: You could remove the UI without removing simpletest and you could remove simpletest without removing the UI.

Proposed idea

  • Move everything UI related into a simpletest_ui module, or maybe even testing_ui module, given it is not just about simpletest
  • Keep the CLI for simpletest in place. The simpletest_ui will be just the user interface you can access via HTTP. run-tests.sh will stay as it is.
  • Add a dependency onto simpletest in simpletest_ui

When this is done, we would have a easier time to do either of the two actions above potentially.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

↧

File Field design update: Upload field.

October 17, 2013, 1:22 am
$
0
0

Problem/Motivation

In terms of interaction, file fields could be a lot more accessible. The style guide proposes both a new appearance and a new interaction design.

Proposed resolution

  1. Files can be added from the local filesystem using drag-and-drop, or using the traditional click-browse-attach workflow (which hands the action off to the OS and back)
  2. Files upload automatically once added by dropping or browsing.
  3. Uploaded files provide a preview where possible (images) or a file-type-specific icon where not.
  4. File fields with multiple attachments use progressive disclosure to reveal each additional slot in turn. They should support dropping multiple files onto a single dropzone to upload multiple files at once.
  5. The “Browse Library” functionality is speculative at this time, but designed to accommodate contrib.
  6. Some aspects of the design are postponed to follow ups (improving multiple file fields, the progress bar, mobile improvements). See the complete list below.

An important reason to encapsulate much of this functionality, is that it tends to scale much better amongst many items and especially if placed between forms it can serve as a clear visual landmark.

Aspects of proposed design postponed to follow-ups

Image may be NSFW.
Clik here to view. 11.file-field.png

Test Pages

  • A file field will have to be created and add to an existing content type

Screenshots (patch #191)

Empty file/image fields
Image may be NSFW.
Clik here to view. Empty file/image fields

Filled file/image fields
Image may be NSFW.
Clik here to view. Filled file/image fields

↧
↧

Convert the error handler to a class

September 17, 2018, 4:58 am
↧

Highlight active element while working with dialogs in Layout Builder

August 24, 2018, 7:59 am
$
0
0

Problem/Motivation

In Layout Builder, when the user chooses the options "Add Block", "Configure Block", "Remove Block", "Add Section", "Remove Section", "Configure Section", a dialog opens. Once the dialog is open, there is no visual indication of the Block/Section is is acting on. In some cases, this active element is pushed out of the viewport. This can make working with dialogs very confusing.

Proposed resolution

  • The clicked element opening the dialog should remain within the viewport after the right panel appears (canvas resizing can push it out of view)
  • The area of the page the dialog is acting on should be outlined.

Example:
Image may be NSFW.
Clik here to view.
Originally from From #2940212-12: [meta] Miscellaneous UI issues for the Layout Builder module

Remaining tasks

Reviews

User interface changes

Element triggering dialogs will be highlighted. If the dialog appearing pushes the element offscreen, the page will automatically scroll to bring the triggering element back into view.

API changes

None

Data model changes

N/A

Release notes snippet

N/A

↧
Search

Layout Builder's Field Blocks do not work with Quick Edit

February 28, 2018, 11:06 am
$
0
0

Problem/Motivation

When Layout Builder and Quick Edit are enabled, it's expected that Entity Fields are still quick-editable when rendered by the Field Block. It appears that the expected data-quickedit-field-id attributes are not being output, and as a result no fields are quick-editable when Layout Builder is enabled.

Proposed resolution

Panelizer has this exact same problem, which was addressed in #2693163: Quick Edit support for fields displayed using the ctools_field block.. We can probably replicate the logic and tests there in Layout Builder without any issues.

Remaining tasks

Write and review a patch.

User interface changes

None.

API changes

\Drupal\layout_builder\Entity\LayoutEntityDisplayInterface::getRuntimeSections() is now a public method.

Data model changes

None.

↧

Allow custom input types for textfields

August 4, 2015, 6:21 am
$
0
0

When trying to theme a form and using the HTML5 input types, D7 ignores the "type" attribute because it is hardcoded to "text". Attached patch will only hardcode to text if no alternative type is specified.

Example code:

$form["element"]["#attributes"]["type"]="number";
↧
↧

Remove scor from MAINTAINERS.txt

February 8, 2019, 1:24 pm
$
0
0

I've had no time to contribute to Drupal for far too long now, and this should be reflected in MAINTAINERS.txt.

I've met so many of you through my contributions to Drupal over the years. Thanks to all the fellow contributors who helped me navigate core and all its APIs from all the way back in 2007. I keep fond memories of all the Drupal events I attended ;)

↧

Add recently removed maintainer to 'Past core maintainers' page

February 28, 2019, 6:55 am
↧

[META] Remove deprecated modules on the Drupal 9 branch

November 13, 2018, 12:54 am
$
0
0

Problem/Motivation

There are/will be some deprecated modules in D8.

- entityreference (Moved form core to Core)
- migrate_drupal_multilingual (functionality will be merged in migrate_drupal)
- block_place (functionality will be merged in block)
- settings_tray/toolbar (maybe create new module)
- field_layout (replaced by layout_builder)
- action -> action_ui
- block -> block_ui
- simpletest -> phpunit_ui (#3028663: Split up simpletest into simpletest and testing_ui to enable easier decisions for Drupal 9, #2866082: [Plan] Roadmap for Simpletest, #2312191: Change Simpletest UI from a test runner to a CLI snippet generator)

Proposed resolution

We can do that now with an update hook and a hook_system_info_alter and then we just remove the system_info_alter later?
The module would be there to remove it from dependencies for other modules and trigger_error.

Remaining tasks

Decide the list of modules.

User interface changes

None

API changes

None as these APIs are already deprecated.

Data model changes

None.

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