Adopting the naming conventions defined at "CSS codings standards for Drupal 8" to layout classes
The layout classes core applies to the body tag should be updated appropriately.
.sidebar-first
.sidebar-last
.no-sidebars
.two-sidebarsshould be...
.l-sidebar-first
.l-sidebar-last
.l-no-sidebars
.l-two-sidebarsNot applicable
Not applicable
Updated: Comment #38
See details about the Usability Study at http://groups.drupal.org/node/163894
This issue contains suggestions and attempts to modify the display of these to fields to make it clear to the user how to 'update' the account password.
During a usability test, users logged into Drupal could not determine how to update their account password. Users did not understand that the existing 'password' and 'confirm password' fields on the user/edit page served the purpose of a password update.
1. Change the name of the field to "New Password"
Suggested in #11
2. Move password fields to the end of the form
3. (rejected) Move password fields into a fieldset
See #19. Concern is that users do not put in the old password when changing a password, so they have to fill out the form again.
4. (rejected) Move password fields into a collapsed fieldset
Same concerns as for fieldset.
5. Move everything but password, email, and username fields to their own tab
See #9
The issue needs a mockup / wireframe of the proposed layout (for alternatives that do not use fieldset)
@Bojhan asked in #30 for a non-fieldset solution that might be:
Updated: Comment #0
When grepping to determine the scope of #2049207: [Follow up] Replace .tpl.php with .html.twig in documentation it was determined that the "Theming information" functionality in Views still refers to .tpl.php files and is broken.
Remove this functionality, twig_debug either already does or will soon replicate this functionality in HTML comments.
None
You should see the contents of the currently used template for rows. Currently this is empty.
The "Theming information" UI will look for .html.twig files instead of .tpl.php files.
Screen shots from #12
Before #9:
After #9:
n/a
We currently have no real styling for the modal in core, it was placed in with little to no styling. We propose to align this styling with the overlay, #1953374: Implement Seven style guide for core overlay, because conceptually they are not very different. Users often interact with the overlay just like a modal, and the modal is often something placed on top of the overlay (e.g., views).
This design may need to be tweaked and revisited depending on the fate of the Overlay.
We've had some recent WSODs and critical validation errors on core Field API widgets:
#557932: Taxonomy term field autocomplete widgets never validate, always lose values.
#557924: Options widget broken
Both of these widgets have things in common: they both use custom multiple values handling. They also have something in common with other D7 core Fields: very little test coverage. The only widgets with any tests in core are text_textfield and text_textarea.
We have a few issues that need to implement SVG images in HTML.
We already defined a good process for CSS in #1963886: Use HiDPI icons in the toolbar but we still haven't agreed a good way to do this inline.
.
The Re-run tests button in the Simpletest UI unfortunately got broken by #1938926: Convert simpletest theme tables to table #type
Attached patch fixes it + additionally cleans up the test results page output to remove unnecessary fieldset wrappers.
This is a bug fix, and normally a bug fix should add test coverage. But I object to add tests for this to Simpletest, because it's a developer tool.
the classList.js (1.84KB) only used in active-link.js.
and Only used 2 simple function:
activeLinks[i].classList.add('active');
activeLinks[i].classList.remove('active');It can replace with:
// add class
el.className += '' + className;
// remove class
el.className = el.className.replace(new RegExp('(^|\\b)' + className.split('').join('|') + '(\\b|$)', 'gi'), '');In D7, if you click the "edit shortcuts" link on your Shortcuts bar, it takes you to the list of shortcut links, which seems very logical to me.
In D8, if you click the "edit shortcuts" link, you are instead taken to the tab where you can edit the name of the shortcut set, which is very unlikely to be what you wanted (really, how often would you want to do that? when you see a list of shortcuts and click "edit", wouldn't you logically want to modify the links in some way?).
So I think this is a UI regression bug. Can you switch it back?
This is a follow up issue to the locale #1627006: Collect project information for translation update
core/modules/locale/locale.compare.inc has a check to see if the project information might be out of date.
// Get project data from the database.
$result = db_query('SELECT name, project_type, core, version, server_pattern, status FROM {locale_project}');
//
if ($result->rowCount() == 0 && module_exists('update')) {
// At least the core project should be in the database, so we build the
// data if none are found.
locale_translation_build_projects();webchick pointed out in #1627006-56: Collect project information for translation update
This may not be sufficient to check if the information is out of date for sites that are not running cron.php regularly.
Sutharsan commented #1627006-86: Collect project information for translation update that:
For a start, sites that do not run cron for longer time will fail. Core build in cron trigger fires daily. If the locale_project table is empty Locale module is probably freshly enabled but while Update module is disabled. It would be a bad first experience indeed. We could fall back to the system table which holds most of the data we need, except for the project name. It is not an easy task to extract the project name from the file and module name and the results may not be reliable. If we think this should be solved, make it a separate issue.
AFAICT, there is no testing on D7 of the user password link functionality.
UserPasswordResetTestCase tests:
- the user can request a reset link
- an expired reset link fails
- an incorrect login attempt prefills the reset password request form
But it does not test the workflow of following a reset link and resetting the password.
This could probably be cribbed in part from UserPasswordResetTest::testUserPasswordReset().
Remote: https://github.com/paulirish/matchMedia.js
matchMedia is written with debounce feature now.
- reduce dependencies & added "matchmedia.addListener" ( sometimes, it only need matchMedia )
The UserPasswordResetTest::testUserPasswordReset() is bogus, since the drupal_get_hash_salt() uses a different $databases array to create the salt.
On the first request the databases connection does not contain the simpletest prefix, on the call initiated from user.pages.inc (user_pass_reset function) it does contain the prefix, so the return value is different #sadpanda
Possible solution: use a test module and hook_boot to set $drupal_hash_salt.
The Integer field will accept integers between a given minimum and maximum value. A validation error is thrown if the number falls outside this range.
But the field does not validate and throw errors for the following cases
The problem is that these values "pass" validation and the value are then committed. But the database field type is int, and the field value is returned as empty.
Add validation for non-digit values and non-integer values.
Add 2 tests, for each validation case.
Write the validation cases.
Write the tests.
None.
None.
see https://drupal.org/node/2208203 for more info
the isssue is that the menu system silently fails and grants access if an access function cannot be found. There should be a watchdog entry or just a big BOOM.
Updated: Comment #N
Right now, entity fields can optionally only exist on certain bundles but the same fields can not differ between bundles. Configurable field instances can have different settings per bundle and base fields can be different as well, for example the node title label can be configured per node type.
Due to that, Field API currently has a few workarounds that involve manually creating entity objects, which is very slow and a large performance problem.
Standardized terminology: base fields are all entity fields that exist independently of the bundle.
Unify and extend Entity::baseFieldDefinitions() and hook_entity_field_info() with by bundle variants:
Entity class methods
Changed: $EntityClass::baseFieldDefinitions($entity_type_id) to $EntityClass::baseFieldDefinitions(EntityTypeInterface $entity_type)
New: $EntityClass::fieldDefinitionsByBundle(EntityTypeInterface $entity_type, $bundle, array $base_field_definitions)
Hooks
Renamed: hook_entity_field_info($entity_type) to hook_entity_base_field_info(EntityTypeInterface $entity_type)
Renamed: hook_entity_field_info_alter(&$info, $entity_type) to hook_entity_base_field_info(&$base_field_definitions, EntityTypeInterface $entity_type)
New: hook_entity_field_info_by_bundle(EntityTypeInterface $entity_type, $bundle, $base_field_definitions)
New: hook_entity_field_info_by_bundle_alter(&$field_definitions, EntityTypeInterface $entity_type, $bundle)
The bundle for EntityManager::getFieldDefinitions($entity_type_id, $bundle) is now mandatory. EntityManager::getBaseFieldDefinitions($entity_type_id) has been added to allow to to fetch the base field definitions. This makes it clear that the common use case is to specify the entity type and bundle.
Additionally, the patch implements this for the node title field, which allows to remove the currently existing overrides and various simplification and improvements in multiple places.
EntityManager::getFieldDefinitions() allows for optional fields per bundle, but doesn't allow for a field of the same name to have different definitions per bundle. However, we need to allow for node titles to have potentially different labels per node type, and likely other use cases as well.
https://docs.google.com/document/d/1A5BLd-KmrLnJW88SdLX5HG3Xm7AyinxwXNAG... has notes from Prague about this.
Issue #2152217 by steveoliver, joelpittet, hussainweb, shanethehat, jenlampton, kpa, AnythonyR, EVIIILJ, kgoel, Cottser, dsdeiz, hanpersand: Convert theme_form_required_marker() to TwigConvert theme_form_required_marker() to a Twig template.
@todo
Split up from from #2095303: Rename 'field_entity' to 'field_config' and 'field_instance' to 'field_instance_config'
We can keep working in the same branch - field_config_entities_rename-2095303
core/includes/menu.inc