Fatal error: Cannot access empty property in modules/field/field.attach.inc on line 324I get this error when block rendered by views starts loading. Error is only on front page. Line 324 of field.attach.inc is:
$grouped_items[$field_id][$langcode][$id] = isset($entity->{$field_name}[$langcode]) ? $entity->{$field_name}[$langcode] : array();
There is few sites with same error:
http://www.takepart.com/2012/06/26/south-korea-protects-bottlenose-dolph...
http://www.alfavita.gr/webtv
I need an user action to unblock users, and modifying user.module solved this for me.
The action lets me do unblocking using the rules module very straightforward.
Attached is a patch to user.module that implements function user_unblock_user_action().
Patch is done against user.module in drupal 6.13.
Note: This is a patch to solve a particular issue on the site I'm building. There are probably
cleaner ways to deal with this problem. I spent too many hours trying to find a solution already
though, so I solved it this way. I don't propose this is a good solution to go into core, but
rather an example of my feature request.
Been looking at this for a while now and can't seem to find a solution. I have a custom REST resource that implements a GET, POST, PATCH and DELETE method using basic authentication and json as the format. The GET, PATCH works, but on the POST I always get a 405 error back:
Client error: `POST http://api_host/rest/my_custom_path/foo/bar?_format=json` resulted in a `405 Method Not Allowed` response:
{"message":"No route found for \u0022POST \/rest\/my_custom_path\/foo\/bar\u0022: Method Not Allowed (Allow (truncated...)
I defined my custom resource as:
/**
* @RestResource(
* id = "custom_resource_id",
* label = @Translation("Custom resource"),
* uri_paths = {
* "canonical" = "/rest/my_custom_path/{arg1}/{arg2}"
* }
* )
*/
class ContentSynchronisationAPI extends ResourceBase {
...
}This is how I call it from another module in an other website:
$client = \Drupal::httpClient();
$token = $client->get("{$api_host}/rest/session/token")->getBody();
$response = $client->post("{$api_host}/rest/my_custom_path/foo/bar", array('headers' => ['Content-Type' => 'application/json','X-CSRF-Token' => $token
],'auth' => array($username, $password),'body' => $json_decoded_data,'query' => ['_format' => 'json'
]
));The user that is used has a role that has the "restfull POST custom_resource_id" permission set.
Is this a known issue with POST?
It seems that the "Skip comment approval" permission is not considered when creating comment via POST.
Comment module handles this via $status = ($this->currentUser->hasPermission('skip comment approval') ? CommentInterface::PUBLISHED : CommentInterface::NOT_PUBLISHED); but in rest.module status is always true.
Check for "Skip comment approval" when setting status for comment entities.
1. Write a test to confirm this.
2. Patch.
We create the key_value table on the installation of the system module.
Let's make that lazy like for example the cache system.
This issue is the obvious followup to #1446650: After installing module display link to "install another module".
Make installing another theme easier by linking to the install page after a new theme is installed.
Add a "Download another theme""Install another theme" link after a new theme is installed.
Also, to match setup of core/lib/Drupal/Core/Updater/Module.php, set up row of links in the following order:
Reviewed and Tested by the Community.
From core/lib/Drupal/Core/Updater/Module.php:
/**
* {@inheritdoc}
*/
public function postInstallTasks() {
// Since this is being called outsite of the primary front controller,
// the base_url needs to be set explicitly to ensure that links are
// relative to the site root.
// @todo Simplify with https://www.drupal.org/node/2548095
$default_options = ['#type' => 'link','#options' => ['absolute' => TRUE,'base_url' => $GLOBALS['base_url'],
],
];
return [
$default_options + ['#url' => Url::fromRoute('update.module_install'),'#title' => t('Install another module'),
],
$default_options + ['#url' => Url::fromRoute('system.modules_list'),'#title' => t('Enable newly added modules'),
],
$default_options + ['#url' => Url::fromRoute('system.admin'),'#title' => t('Administration pages'),
],
];
}| Task | Novice task? | Contributor instructions | Complete? |
|---|---|---|---|
| Update the issue summary | Instructions | Done | |
| Manually test the patch | Novice | Instructions | Done |
| Embed before and after screenshots in the issue summary | Novice | Instructions | Done |
Before: 
After: 
None
In #2664322: key_value table is only used by a core service but it depends on system install there were test failures with PostgresQL in ConnectionFailureTest that seemed to be caused by the Connection class having an incorrect statementClass.
Add a check to Drupal\Core\Database\Driver\pgsql\Connection::prepareQuery() to make sure that $this->statementClass is set correctly.
Add a test that reliably recreates the race condition (or artificially munges $this->statementClass) that triggers the test failure.
None
None
None
Firefox 49 is out and has support for <details> which means our polyfill doesn't kick in. Normalize.css sets <details> and <summary> element as display:block which means Firefox won't display the marker, they fixed this in 5.0.0 (https://github.com/necolas/normalize.css/issues/604).
Checkout comparison aligned by @droplet: (removed comments & unchanged rules, re-reordering to match v3)
https://www.drupal.org/files/issues/diff-manual-aligned-by-%40droplet.patch
Here are the change logs for Normalize.css, starting at 4.0.0 (scroll up): https://github.com/necolas/normalize.css/blob/f06565fe8e0e1ad1b88f273271.... There are a lot of changes due to reorganization/sectioning of the code as well as comment changes.
There is one notable change that causes a regression in, at least, Seven: https://github.com/necolas/normalize.css/commit/02c5c7adbbec1707900fde86..., see the attached screenshot.
There may be regressions upgrading from 3.0.3 to 5.0.0 of normalize.css.
Upgrade Normalize to 5.0.0 and move relevant CSS from the changes between 3.0.3 and 5.0.0 to Stable theme.
Hopefully none!
Noticed as part of #2501683-46: Remove SafeMarkup::set in _update_message_text()
the words "available updates" linking to two different pages in the same paragraph
Unknown release date (version 8.0.0-beta11 available)There was a problem checking available updates for Drupal. See the available updates page for more information and to install your missing updates. 
change one of the links to better indicate where it goes
| Task | Novice task? | Contributor instructions | Complete? |
|---|---|---|---|
| Create a patch | Instructions | ||
| Manually test the patch | Novice | Instructions | |
| Embed before and after screenshots in the issue summary | Novice | Instructions | |
| Review patch to ensure that it fixes the issue, stays within scope, is properly documented, and follows coding standards | Instructions |
No new patterns. Change in links in text.
No.
No.
This issue is intended as a tracking issue only to list all of the known intermittent test failures affecting Drupal core. Some issues are due to bugs in Drupal core; others may be due to issues with DrupalCI infrastructure.
Only open issues should be listed in the summary.
None at present.
The help text of the Content Moderation module does not follow the Help text standards as described in https://www.drupal.org/help-text-standards.
The descriptions should be so generic that they work for example for different admin themes where links are not displayed as blue buttons, and they should contain the relevant links.
Editing the text according to the standard.
This is a UI text change
It's more useful to show the user what they are typing instead of asking them to type it twice:
http://www.lukew.com/ff/entry.asp?1653= (2012)
http://www.lukew.com/ff/entry.asp?1941 (2015)
Add a password field with show/hide functionality and make it an option to use this instead of the password_confirm field
The password confirmation field can be removed and replaced with a show/hide link
| Issue category | Feature because usability improvement |
|---|---|
| Issue priority | Not critical because usability improvement |
| Unfrozen changes | Unfrozen because it only changes CSS/markup |
| Prioritized changes | The main goal of this issue is usability |
The datetime views plugins have wonky timezone support. This needs to be fixed. While most evident in the argument plugins, the filter, and sort plugins have similar problems.
Because of coupling with the views architecture, fixing the individual plugins with separate issues is essentially impossible. In addition, a proper fix means moving some backend specific code out of the generic Sql class (date handling in SQL is not equivalent between the supported databases), and fixing some date support in Views itself.
Cry, then fix all the things and provide test coverage.
None.
TBD. It looks like some very low level Views classes may have interface changes.
The datetime View Arguments don't take into account the user's timezone. That means that if you make a View that has \Drupal\datetime\Plugin\views\argument\YearDate argument then all users will same events even if the timezone for a user would push certain events into either the next or previous years.
This is probably an edge case for years but for the new arguments in #2567815: Add week, date, and year-month Views argument plugins would be more effect by this.
So if you used the FullDate argument then dates that would be in a different day because of the user's timezone don't show up correctly.
Working on a patch
I am unable to upload images in custom content type when this content type also contains fields of type integer
Reproduction steps:
- create a new content type and add two custom fields: an image and an integer field (use standard options for both)
- create new content of this new content type and upload an image
Expected result:
- after selecting an image to upload the upload image box should transform and show a small version of the uploaded image as well as present a box to enter the alt title of the image
Actual result:
- nothing happens. When opening a browser console you will see an javascript ajax error
This issue is reproducible in both Chrome and Firefox. If I delete the integer field and then create new content, everything works as expected.
Not sure which component to set but set it to ajax.
Hi,
While working with the Drupal's theme layer to have a better support of different theme engines in our beloved Drupal 7, Pounard discovered that Drupal's templates must have two dots in their names.
The explanation:
A theme engine may only use a 2-part extension (eg. ".tpl.php" or ".html.twig") but cannot use a single part extension (such as ".phtml" or ".twig"). No one ever saw that comming, because almost no one actually write theme engines, but in the end, this as another side effect: you cannot name your templates "some.thing" (for exemple, that would tie to the "some_thing" theme hook).
I suggest you to read the full explanation and its very interesting side effects.
As we cannot mix issue on Drupal.org, we will provide a patch for this issue only.
#1838242: Provide Views integration for datetime field uses hook_field_views_data() to add proper views integration. However, due to limitations of the Views API, this mechanism does not work for base table fields.
Datetime is the *only* module that adds field types, apparently (the rest have moved into \Drupal\Core), so until #2337515: Allow @FieldType to customize views data is in this might be overly complicated.
TBD
Find a solution
N/A
N/A
LanguageSelectWidget hardcodes the list of languages to LanguageInterface::STATE_ALL. While that's a reasonable default it should be possible to configure it to use LanguageInterface::STATE_CONFIGURABLE (i.e. without Not specified and Not applicable).
Add a include_locked setting for LanguageSelectWidget with a corresponding checkbox in the settings form. We should probably make the label a bit more explicit, such as:
Include locked languages such as Not specified and Not applicable
Depending on that setting either use LanguageInterface::STATE_CONFIGURABLE or LanguageInterface::STATE_ALL as the #languages.
None.
None.
An additional setting for form displays using the language widget.
Making public from issue reported on s.d.o against 7.x
"Drupal logs unsuccessful login attempts via watchdog in to following format:
Login attempt failed for [contents of username field]
Anecdotal evidence shows that a users commonly make the mistake of entering both their usernames and passwords in the username field. For example, this is common among keyboard navigators who focus first on the username field and then (unsuccessfully) tab to the password field, enter their password and press enter.
The result is Drupal storing the user's password in plaintext. If the database is compromised, it would be easy for an attacker to determine passwords.
I suggest adding a check to user_login_final_validate() that ensures what has been entered in the username field is indeed a valid user before logging it to watchdog. If it is not a valid user, log it IP address instead."
Symfony 3 is here, we decided to adopt it for Drupal 8 in #2395443: [policy, no patch] Follow symfony 2.7 or 3.0., this is the question.
Prepare Drupal core to use Symfony 3.
Fix #2712633: Update symfony-cmf/routing to 1.4.0.
Fix #2712637: Update stack/builder for Symfony 3 compatibility.
Fix #2712643: Update behat/* to 1.7.1 and fabpot/goutte to 3.1.2.
Fix #2720869: Remove the use of deprecated CssSelector and use CssSelectorConverter instead.
Fix #2720891: Replace ContainerAware with ContainerAwareTrait
Fix #2721139: Replace deprecated files ParameterBag usage.
Fix #2721179: Replace deprecated Symfony ExecutionContextInterface.
Fix #2726645: Do not @deprecate EntityManager until all usages are removed (helps the Symfony 3 update).
Fix #2728815: Batch API uses request attributes instead of query in Symfony 3.
Fix #2730129: DrupalKernel must never persist service_container for Symfony 3 update.
Fix #2682373: Implement ContainerAwareEventDispatcher::getListenerPriority().
Fix #2776105: Update asm89/stack-cors for Symfony 3 compatibility and revert changes introduced by #1869548.
Fix #2823687: Use isMethodCacheable() instead of isMethodSafe() when checking for GET/HEAD.
Fix fails.
Review.
Commit.
None
Hopefully none
Not yet