I'm creating the second page display to the Frontpage view with the same path: /node. After setting this newly created page display Access Settings Role - Administrators, the entire frontage is not accessible to Administrator: "You are not authorized to access this page." Reordering the page displays does not solve the issue.
I'm using Drupal8rc2 with Acquia Dev Desktop
Version: 2
Built: Oct 22 2015 11:06:00
Control panel rev: ee456cf
Stack rev: c79bd0c
The docblock for function doBookTreeBuild in BookManger.php class is missing both @param and @return directives. The @param directive for $parameters variable should include an '(optional)' string to start its description.
There is an issue with the Devel module conflicting with the Dashboard module. At admin/structure/dashboard blocks can be successfully placed into dashboards regions. However, at admin/dashboard dragged blocks don't retain their new location. This is because the Devel module, which has the "switch user" block, is converting underscores to hyphens when blocks are rearranged on the dashboard, affecting block CSS IDs and block deltas.
Steps to replicate:
Add module-<module name> and delta-<delta> classes to enabled blocks.
Patch in #16 implements this fix for D7 and D8.
Two additional CSS classes will be available on dashboard blocks: module-modulename and delta-N. Blocks will be correctly ordered based on these classes.
None.
At admin/structure/dashboard I can place blocks into two dashboard regions, yet at admin/dashboard I still appear to be free to move them around to either region ... except that when I click 'Done', the ones set at the first page snap back.
This is confusing. In fact, the whole business of having two pages is confusing -- the UI doesn't explain why there are two and how they relate to each other.
Originally a follow-up to #2572929: Document lack of auto-escape in theme functions and add a theme autoescape helper function but expanded to cover the more general case.
Drupal 8 has numerous deprecated functions and class methods.
There is at least one deprecated function argument #2431297: Remove unused parameter from BookManagerInterface::getActiveTailIds().
Additionally there is deprecated functionality such as theme functions (which boils down to a deprecated info.yml key).
A few things to figure out:
1. We have no convention for documenting @deprecated for parameters. http://phpdoc.org/docs/latest/references/phpdoc/tags/deprecated.html does not help.
2. For some things like theme functions, we'd have completely removed support for them if we'd had time to it between removing core usages and the release candidate, and we'd like to actively discourage people from using them at all due to security concerns. E_USER_DEPRECATED could work for this.
3. For things that are just deprecated, we might also want to use E_USER_DEPRECATED - as part of the process of helping people get their modules ready for 8.x (i.e. if you can run all your tests without any E_USER_DEPRECATED, you know you're up to date with the bleeding edge of 8.x, rather than having to look through docs etc.).
Figure out how to use E_USER_DEPRECATED, as well as docs for things that don't have their own dedicated docblock.
TBD
None.
Possible deprecations; no BC breaks.
None.
There are some calls to methods on the idMap through out the sourceBase but it isn't initialized until the rewind() method is called. This generally works because those methods are called with in a loop so rewind() has been called but there isn't a requirement on all of those and it will cause a fatal if that happens.
I left this normal. It would be minor in my opinion but the fatal is a pretty big consequence of the edge case.
Initialize idMap in constructor.
Not sure if this qualifies as a bug, since it generates a "notice" and not an "error." However, after upgrading to version 7.26 of drupal core, I began seeing the following notice with increased frequency in the logs:
Notice: Undefined property: stdClass::$nid in node_tokens() (line 112 of /home1/zonesny/public_html/modules/node/node.tokens.inc).
If I hack the node module (just to test and temporarily quiet the logs--I know this goes against the Prime Directive), and add a check for the value of nid, then I no longer see the notice.
/* Made the following change to line 105 in node/node.tokens.inc., based on <a href="https://drupal.org/node/1817992" title="https://drupal.org/node/1817992">https://drupal.org/node/1817992</a> */
// if ($type == 'node'&& !empty($data['node'])) {
if ($type == 'node'&& !empty($data['node']) && !empty($data['node']->nid)) {Stub entities are created with wrong default values, because all empty entity properties are initialized with null in migrate itself. The attached screenshot illustrates the problem.
The base Entity destination plugin should provide default values for unpopulated required fields in processStubRow(). Where that isn't good enough for specific entities, they should override processStubRow() to add their own processing.
Tasks:
Entities working with stubbing:
Entities not currently working with stubbing:
The patch currently contains work-arounds for the following core issues - ideally we would like to get as many of these as possible committed and remove the work-arounds from this patch before committing it (and yet we would also like this patch in ASAP).
N/A
None
None
I'm getting a 500 server error when I try to log in at /user. Also one of the pages that has the contact form on it gives out the same error. The rest of the site works fine.
I checked the error log and it's this error ...
PHP Fatal error: Call to undefined function form_process_autocomplete() in /home/ .... /includes/form.inc on line 1850
Anything with a form field seems to kick out the error. Is there a patch?
Thanks.
Many of the function docblocks in WebTestBase are incomplete. Some @return missing or incorrect.
Review the docblocks and fix any incorrect tags.
None.
None.
None
During installation a profile can override configuration provided by modules. However this is limited to install time. If a profile wants to provide a different default for a module that is installed after the profile installed it can't. This was a designed limitation of the ConfigInstaller. However, it is apparent that we have use cases for this. Not least with the testing profile in core which wants to disable translation download. To do this it has the file core/profiles/testing/config/optional/locale.settings.yml. This currently does not work, which results in the test run downloading translations unnecessarily.
Another upside of this change is that we become more friendly to distributions as they can override configuration for modules they don't enable but want to provide a specific opinionated default config for in case the user does install that module.
Always check the profile module's optional and default configuration folders for overrides regardless of whether we're doing an installation.
Review
Commit
None
None
None
The patch includes a signature change for a protected method.
We added this issue a few weeks ago, it's happening since RC1:
It's still happening on RC3.
#2585205: No results behavior showing html markup code
When adding a "NO RESULTS BEHAVIOR" for a field in a view, the view is showing the HTML markup code instead of rendering it.
We are using:
Drupal core 8.0.0-rc1
Standard Profile
Follow-up to #1825952: Turn on twig autoescape by default
After #2264041: Add a test to ensure title callbacks are not vulnerable to XSS have proven that even battle hardened core developers can't write XSS free code we have introduced #1825952: Turn on twig autoescape by default to fix a torrent of security holes already present in core known and unknown and to avoid the most frequent kind of sechole(Security Hole) in the history of Drupal contrib. However, this has broken some places that were already securely written, resulting in broken layout and HTML tags shown to users. We need to find those places and update them to be compatible with the new method.
#1825952: Turn on twig autoescape by default fixed escaping globally and caused HTML escaping on places where we explicitly set HTML in a variable. This was expected. The patch was an absolute must and avoiding / fixing all paths would've taken a lot of time and made an already big patch impossible to review and commit.
Instead we have opted to go ahead with this and let people find the broken pages. If people would've cared to review patches this could've been avoided but we know this is a no-go so instead we forced it.
@ti2m found escaped strings on several paths:
Another (and the last) update on the crawled urls. I enabled all modules on a fresh install and crawled the site as user 1. I only found two more urls with escaped strings (first two in the list below). But the general problem is, that e.g. node edit forms aren't covered at all as no node exists on a vanilla install. I could post a file with all covered urls, roughly 300, if anyone is interested.
The total list of urls with escaped HTML strings that I found:
- /admin/config/regional/translate/settings
- /admin/config/development/logging
- /admin/modules/uninstall
- /admin/config/regional/date-time/formats/add
- /admin/config/regional/date-time/formats/manage/long
- /admin/config/people/accounts/fields/user.user.user_picture
- /admin/config/content/formats/manage/basic_html
- /admin/structure/block
- /admin/structure/block/list/seven
- /admin/structure/views/nojs/rearrange-filter/frontpage/page_1
- /admin/structure/menu/manage/footer
- /filter/tips
- All 'manage fields' pages (ref: Screenshot)
If at all possible move all markup into a Twig template. If not then please read https://www.drupal.org/node/2311123 for alternative solutions. See aneek's patch at #2305831-35: Double escaping on /admin/modules/uninstall for an example.
Change the offending pieces to properly use Twig templates or use inline templates as described in https://www.drupal.org/node/2311123 .
As per Drupal 7 and 8 beta, instructions in default.settings.php need to be more user friendly.
A new user or novice will not know what must be uncommented in that file to configure the database connection. This is a real issue: not only is it critical for installation to succeed, it is a turn-off and intimidating.
The configuration options below the database part are more clear, but for the first basic part to set-up the database, more user friendly phrases need to be added, such as "Uncomment the following lines (except @code and @endcode) and replace the words databasename username and password with those that apply...".
Here is another example of what cannot be understood :
* WARNING: These defaults are designed for database portability. Changing them
* may cause unexpected behavior, including potential data loss.
*
* @see DatabaseConnection_mysql::__construct
* @see DatabaseConnection_pgsql::__construct
* @see DatabaseConnection_sqlite::__constructA positive example is the .htaccess file, which clearly uses phrases like "You may uncomment the following line if...".
As Drupal 8 must be user friendly, and as even an experienced Drupal user like myself had to search the web to feel more at ease with default.settings.php (as of current Drupal 7 and Drupal 8), I think this task is fundamental ("The major priority is used for issues that are not critical, but that do have significant impact...").
image-rotate-summary.html.twig contains untranslatable string. It is possible a translate interface bug.
In the file:
random between -{{ data.degrees|abs }}° and {{ data.degrees|abs }}°on the ldo
https://localize.drupal.org/translate/languages/hu/translate?sid=292906
random between -@degrees° and @degrees°or
random between -° and °Updated #204
Part of #1823450: [Meta] Convert core listings to Views. This also helps solve problems for #1978904: Convert comment_admin() to a Controller and #1946348: Convert all of confirm_form() in comment.admin.inc to the new form interface which currently needs special handling for confirm delete forms.
Converting the admin/content/comment* page to a view with operations would keep it more inline with the rest of core listing pages.
Fix failing tests.
Review.
Manual testing.
N/A
Copied from https://www.drupal.org/node/1823450#beta-evaluation
This is appropriate for 8.0.x.
| Issue category | Task because the functionality of these listings is already in core (with custom code) |
|---|---|
| Issue priority | Major because this Meta is about replacing core listings in many places, across systems, and has community consensus for being important. Not critical because we can release 8.0.0 without completing the conversion to views and do it in a later release. Keeping the custom code (not converting a listing) will not cause severe performance or usability regressions. |
| Prioritized changes | A bit, it maybe would reduce fragility by re-using views code and getting rid of custom listing code. |
| Disruption | It will not be disruptive for core/contributed and custom modules/themes because it will not require a BC break/deprecation/widespread changes since changes are isolated to core listing custom code. |
Sometimes image paths get internal ip-address instead of domain.
Example:
http://10.52.16.57/core/misc/feed.svg
Should be
http://mydomain.com/core/misc/feed.svg
The object comes from the cache_render bin, so I guess that something goes wrong sometimes when the objects is stored in the render cache, the weird thing is that is just sometimes, not always, and I have not succeeded to debug it properly yet. Edit: I also found the same issue in the cache_dynamic_page_cache bin.
An example from the render_cache:
[url.site]=http://10.50.16.57:
This could of course be something in our custom code that creates this problem - but we have it right now on two different sites with different themes. And I am not sure if it is a caching issue or a theme issue, but I guess a theme issue, because of that cache just stores what it gets.
Drupal 8 releases tested: 8.0.0-rc2 and 8.0.0-rc3, same result.
OS: CentOS release 6.5 (Final)
PHP-version: 5.5.20
DB: 5.5.41-MariaDB
HTML5 custom data attribute names containing numerals are getting mangled by \Drupal\Component\Utility\Xss::attributes(). This occurs in Xss::attributes() because the regex pattern in $mode 0 does not match numerals.
Reproduce by running <a data-a2a-url="foo"></a> through Xss::filter:print_r(\Drupal\Component\Utility\Xss::filter('<a data-a2a-url="foo"></a>'));
The data attribute name is stripped from the first numeral:<a a-url="foo"></a>
In attribute names, permit numerals after the first character, because the HTML5 specification permits numerals in custom data attribute names, such as data-j2-range (an example from the spec).
None.
None.
The last sentence in the text information at the top of the admin/config/services/aggregator page still reads "For each feed, the latest items block may be enabled at the blocks administration page." This was correct for D7, but for D8, you place a 'Aggregator Feed' block and select which feed it is to show. I found this confusing, and I almost filed an issue saying that the latest items blocks weren't being created. This should be corrected.