This is a follow up from #2940023: Improve accessibility of Umami's responsive main menu.
The responsive menu in Umami has some accessibility problems:
- The button only does something when JS is enabled. When JS is off, the button is there in markup, but does nothing.
This is a follow up issue from #2940023: Improve accessibility of Umami's responsive main menu
The button is outside the navigation landmark. When closed, a screen reader user might search for the navigation landmark region, but find it empty. They should find the button inside the nav landmark region.
Follow-up to #2263569: Bypass form caching by default for forms using #ajax.
- The added request parameters bleed into links.
- E.g. right-clicking on a newly loaded pager link, returns AJAX
- Remove internal request parameters from the Request object as soon as possible, store them somewhere else, so that later subscribers can still access them.
( Service? Request->param() *brrr*? ... )
- Stalk Crell :-D
- Discuss
Sometimes a contrib module wants to guarantee access to a certain REST resource (some entity type, usually), in a particular format, with a particular authentication mechanism. However, the REST module requires configuration to be created for that, but that means it can be modified by the site owner. Which means the expectations of the contrib module can be violated.
One might say Well, why don't those modules simply provide their own controller?
, to which the answer would be: The problem is that they then must duplicate large portions of
. The point is to rely on the REST module's test coverage/improvements/bug fixes, and to not duplicate all that.\Drupal\rest\RequestHandler to handle serialization+cacheability correctly, and they'd also need to duplicate portions of EntityResource
Enable this use case by allowing the route to specify the plugin to use. This would decouple \Drupal\rest\RequestHandler() from RestResourceConfig config entities.
TBD
None.
None.
None.
When loading large numbers of entities, especially during migrations and updates, it's quite easy to run out of PHP memory.
Migrate works around this by trying to clear the entity static cache, but this also results in a persistent cache clear.
Static caching is hard coded in storage classes which prevents swapping it out unless you change the whole class.
Add a 'static cache' service, which does not serialize at all, but which conforms to CacheBackendInterface.
Rework entity storage to rely on this service instead of a raw class property.
This will allow for two things:
- once this issue has landed, migrate will be able to reset the static cache via the service, therefore not affecting the persistent entity cache.
- in a follow-up, we'll be able to add a simple Least Recently Used implementation, allowing the static cache to have a fixed maximum number of items.
- beyond this, there is the possibility to go even further:
- have a cache backend limited by the actual size of the items in it (will require estimating memory usage of entities)
- add a cache backend, probably in contrib, using PHP weak references http://php.net/manual/en/intro.weakref.php which theoretically will allow cached entities to be removed by garbage collection.
Spinning this out of #1302378: Use multiple specialized entity controllers.
The base EntityController class currently handles keeping it's own 'static' cache internal to the class, or always fetching from the database all the time.
In Drupal 7, this means that http://drupal.org/project/entitycache needs to provide it's own controller class to provide persistent caching for entities.
We can make this a lot more flexible by just replacing the custom caching within the Entity controller class, with a configurable cache controller key instead of the current 'static cache' key. There's no need for entity-specific cache controllers, since any class implementing CacheBackendInterface will do fine.
To allow for 'static' caching, I've added a new ArrayBackend which simply stores cache items in a php array. Apart from expires which didn't seem worth working on until #730060: Replace CACHE_TEMPORARY, cache_clear_all() and minimum cache lifetime with cache tags support is in, this (untested) backend supports everything the database backend does, including tags etc., meaning it should be useful for unit testing eventually.
For no static caching at all, the NullBackend works fine.
To actually implement entitycache in D8 (whether core or contrib), you'd need a backend that proxies the MemoryBackend + whichever one is implemented for the cache_entity bin, since we're placing responsibility for both in a single class doing things this way. There's some inconsistencies with resetCache() etc. that would need to be sorted out for that.
Completely untested patch that will likely blow up, but just to show what it looks like.
One feature gets dropped here, which is fetching from cache when $conditions is passed to entity_load(). That's already a bit wonky as it is, and the $conditions parameter is already on its way out and documented as deprecated in 7.x per #1184272: Remove deprecated $conditions support from entity controller.
When I enable ajax in /admin/content view and try to perform a bulk action I see ajax command JSON on the UI.
Steps to recreate this issue.
I expect this page to reload with the message "Publish content was applied to 50 items", but instead I see ajax command JSON output on the screen.
I've decided to start taking a more active role in core Theme API development considering that we've never really gotten too far past all the Twig conversions since 8.x was initially released.
Currently, Drupal.AjaxCommands.prototype.insert() always wraps the returned HTML in a div. There are multiple conditions where even the more limited DIV wrapping creates problems (see comments #41-#48).
See the consequences of this in massive duplication related issues, and on screens in #331, and on your sites.
The solutions avoids wrapping returned content in all cases where it's possible without breaking existing sites. We will still wrap the inserted markup when trying to insert multiple root elements with a ajax effect. This will be removed from Drupal 9.0.0. For more details: #284. However, the div is now added in a theme function which provides an option for developers to opt out from this.
We can't parse SVGElement without wrapper since innerHTML is only available on HTMLElement. See #316 - #321 about it.
As a result, we decided to first insert the markup into an empty div, and then use .contents() to get the elements (see #336):
// Parse response.data into an element collection.
const $newContent = $('<div></div>').html(response.data).contents();
// ...
// Add the new content to the page.
$wrapper[method]($newContent);
See latest patch
With Drupal's page cache enabled and more than one file upload field on a form, uploading to the first via the "Upload" button and then trying the same for the second produces an erroneous "the uploaded file likely exceeded the maximum file size" error message.
For Drupal 7, #2339109: Multiple file uploads don't work with Drupal cache enabled contains a lot of discussion of the problem and steps to reproduce it using Webform.
I assume Drupal 8 is affected too since the code is similar, but I haven't tested.
One possible way to fix this - just remove the code that throws the error. The error message suggests that it's there to catch cases where a file is bigger than the upload limit supported by the server, although it's not obvious how the code is related to that - clearly there's at least one case (this one) where it works incorrectly. And even so, the form API validation should already be preventing files that are too large from ever being uploaded in the first place.
In manage block, I checked one specific content type in option Visibility, the block is showing only in this content type, the problem is the preview mode, in preview mode this content type is ignored.
- Container compilation is one of the slowest parts in cold cache startup. (now that YAML parsing is cached in FileCache)
- Container compilation is one of the most slowest parts during installation / uninstallation of modules
In the test suite this compilation happens again and again.
The major part in the compilation process taking long is Symfony's dependency checking and graph operations.
However:
- Caching the container across test configurations is very hard as there is many variations and modules are allowed to change everything.
Therefore we have:
- Poor cache granularity (hash is changing too much)
- BC problems as caching the container across tests could not take into account undeclared dependencies that modules have, so caching e.g. just on the module list is not feasible as there can be any outside parameters.
While I tried to cache the hash of the full container definition minus the parameters based on all parsed yml files (which worked great and had not too many variations), there is an even better way:
As seen in the motivation section, the slowest part are the dependency checks.
Those are defined here:
https://github.com/symfony/dependency-injection/blob/master/Compiler/Pas...
However, all this services do not depend on anything external and do also not depend on any parameters (except for the ResolveParameterPlaceHoldersPass, which can be removed as the used container supports run-time parameter resolving)
That means:
Whatever input those passes get in the form of the current ContainerBuilder(), the output will always be the same.
That however means this is cacheable based on the input and fortunately we already can transform a container builder into a container definition array using the PhpArrayDumper() (which is also really fast (8 ms)).
The idea is now to replace all those services with a single service _if_ and only if no one added a compiler pass before or after this - unless it is whitelisted using a special interface.
And doing that we can skip the most expensive compilation steps.
The new pass that replaces those passes, would then):
- Compile to a definition
- Store and remove the parameters
- Create a CID from the hash of the definition
- Put that in drupal.container_definition_cid
Cache Hit case:
- Retrieve the cached definition as the final output result
- Store a parameter: drupal.cached_container_definition (and re-add the original parameters to it).
- Return
Drupal would check the drupal.cached_container_definition parameter and use that instead of dumping the container builder.
Cache miss case:
- Just run the container things
- Create a dump like usual
- Check presence of drupal.container_definition_cid
- Store the result of the definition
Storage would just be in APCu or FileCache with a custom class that does only use the backends, but not the mtime part.
- Do it!
The Umami installation profile has so far been referred to as an "experimental" profile, reusing the concept of experimental modules that has been in Drupal core since 8.0.0.
However the concepts are sufficiently different that reusing the "Experimental" concept for the Umami profile is misleading and potentially confusing.
It is aspired that experimental modules pass through increasing levels of stability until they become non-experimental, IE first class citizens within Drupal core. If this doesn't happen within an agreed time frame*, they are removed from core. This is not the case for Umami, which is intended to retain its current level of stability in perpetuity.
There is also a difference in the context in which we call modules and profiles experimental. A module is experimental because the Drupal community are encouraged to experiment with it to find the rough edges and help gauge whether it is suitable for use in core going forward. The Umami profile is experimental because people who install it might be experimenting with Drupal. They might well not be experimenting, they might be demonstrating Drupal to others, or incorporating it in a training course, or using it to build documentation. It's not a given that the use is experimental.
I think there is potentially a use case for something called Experimental profiles - imagine we hadn't identified the need for Stark, and wanted to introduce something similar in core. Or decided that we wanted to offer a decoupled Drupal installation profile. We could then introduce an experimental profile with the intention it progresses through increasing levels of stability until it becomes non-experimental, in exactly the same way that modules do.
But that's not what Umami is. And labelling it as such would make it even more confusing if we *did* want to introduce a profile that better fits our concept of experimental components in core.
* we potentially may have bent the rules for Inline Form Errors here? But if we did, the aspiration was still there and this doesn't invalidate this point.
Change references to Umami being an Experimental profile to being a Demostration profile.
Build documentation on D.O explaining what that is.
TBD
TBD
TBD
TBD
When cron runs, I get this runtime exception every time, but with various referrers. Most of the cron sessions work fine:
RuntimeException: Failed to start the session because headers have already been sent by "/home1/suppotf0/public_html/core/modules/big_pipe/src/Render/BigPipe.php" at line 264. in Symfony\Component\HttpFoundation\Session\Storage\NativeSessionStorage->start() (line 135 of /home1/suppotf0/public_html/vendor/symfony/http-foundation/Session/Storage/NativeSessionStorage.php).
Follow up to #2208429: Extension System, Part III: ExtensionList, ModuleExtensionList and ProfileExtensionList. A lot of the exceptions in the extension system use \IllegalArgumentException which is too generic. More specific exceptions are needed for specific conditions.
Add two new exception classes UnknownExtensionException and UninstalledExtensionException in the extension namespace and use as appropriate
Patch
Reviews
Commit
None
Two new Exceptions in the extension system
None
I am trying to group counple of exposed filters in a View In the content type called Product, I have a taxonomy vocab 'Product Type' with terms 'Charts', 'Labels','stickers', Friezes'
Now when I add a filter of 'Product Type' Content and expose it with grouped Values
say
Stickers Is one of Labels
Stickers
Charts is one of Charts
Friezes
I get these option on the view but when I select one of them none the valus gets returned.
But if I select 'any' in the same filter all the values are retured. I have tries Views 7.x 3.5 dev version
After #1596472: Replace hard coded static cache of entities with cache backends core with have \Drupal\Core\Cache\MemoryCache\MemoryCache and \Drupal\Core\Cache\MemoryBackend.
MemoryBackend is supposed to be used only for testing, whereas MemoryCache will be used for all entity storage.
Rename MemoryBackend to something else, such as MemoryTestingBackend or similar.
MemoryCache currently extends from MemoryBackend, but when we do the rename we may want to make the new class inherit from MemoryCache instead. Except we probably don't want to do that because MemoryBackend wouldn't confirm to MemoryCacheInterface - so perhaps add a trait instead or just duplicate the code.
1. Created a feature exporting user field settings with the contributed D8 feature module
2. Various changes to the user fields
3. Incorporating my colleagues various changes into my repo
4. Running drush features-import produced this error:
[derp@der[ public]$ drush fia -y
Reverting Base User...
PHP Fatal error: Call to a member function getConfigDependencyName() on null in /var/www/vhosts/derp.dev/releases/herp/public/core/lib/Drupal/Core/Entity/EntityDisplayBase.php on line 274
Drush command terminated abnormally due to an unrecoverable error
Wrap the add Dependency method call on line 274 with a quick !empty check
Umami styles are leaking to the Settings Tray edit button.
It would probably bebetter if this fixed in toolbar module / stable.
Field names are limited to 32 characters, but profile field names may be longer on older sites. A Drupal 6 site with profile field names longer than 32 characters cannot be fully migrated.
Output from drush for a d6 site:
Attempt to create a field storage with an name longer than 32 characters: profile_expertise_electoralsystem [error]
(/www/cn8/core/modules/field/src/Entity/FieldStorageConfig.php:315)
Attempt to create a field storage with an name longer than 32 characters: profile_expertise_executivesystem [error]
(/www/cn8/core/modules/field/src/Entity/FieldStorageConfig.php:315)
Attempt to create a field storage with an name longer than 32 characters: profile_expertise_legislativesystem [error]
(/www/cn8/core/modules/field/src/Entity/FieldStorageConfig.php:315)
Attempt to create a field storage with an name longer than 32 characters: profile_expertise_naturalresources [error]
(/www/cn8/core/modules/field/src/Entity/FieldStorageConfig.php:315)
Processed 39 items (35 created, 0 updated, 4 failed, 0 ignored) - done with 'upgrade_user_profile_field' [status]
The resolution should take into account the field storage limitation to migrate Drupal 6/7 profile fields as field storage and fields, and map these new field names so that a migration of profile values will succeed.
All these requirements are met with make_unique_entity_field and setting a limit to 30 chars. That gives us 99 possible fields on a d6 user and surely is enough for the vast majority of sites.
- Update issue summary to make sure everything is clear going forward- Fix test/patch- Review
N/A
n/a
n/a
@dawehner spotted this whilst we were waiting for a test run to finish.
19:20:10 Drupal\Tests\settings_tray\FunctionalJavascript\QuickEditInt 2 passes
19:25:22 Drupal\Tests\settings_tray\FunctionalJavascript\SettingsTray 22 passes
That's way longer than any other JS test.
Don;t use a data provider. They are really for a unit tests. Using them in functional tests means we have to do a full re-install each time.
none
none
none