When I click the image icon in CKEditor I get a "loading" message and thats all, I can never add an inline image (node, content block etc, makes no difference).
Note the very first time I try to add an image it pops up the dialog (very first time after a clean install), but on subsequent attempts to add an image the dialog never appears etc.
This is a meta/plan issue to keep track of what's needed to make Stable a reality.
base theme in its *.info.yml will use Stable as the base.We want to make Classy depend on Stable.
Currently, fatal errors occur when you try to visit update.php after we remove base theme: false from Classy's .info.yml. For update.php to work the theme displaying it needs to work.
Find a way forward.
TBD
n/a
TBD
None
Stable exists but is not yet stable (no snapshot of markup, CSS, etc. yet).
Before RC we added the Stable theme itself "underneath" themes with no base theme set. We need to copy templates, CSS, and related assets, and add library overrides so that people can start extending from Stable templates rather than core templates, and similar for libraries.
Copy templates, CSS and relevant image assets and use libraries-override to make it happen. Potentially add test coverage here or in a separate issue for certain scenarios: https://drive.google.com/open?id=1rHV4L67W5AIYvmBmovY4p87D4aPcJqn9MchKpY...
Making Classy inherit from Stable is separate: #2581443: Make Classy extend from the new Stable base theme but there may be some automated test fallout to deal with depending on what goes in first.
Because this is a large patch, here's what's going on (in order of the changes in the patch):
Add tests to ensure we have all the Twig templates overridden.
Review!
Should be none.
Should be none.
n/a
Follow-up to #2297711: Fix HTML escaping due to Twig autoescape
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.
Can be tricky to discover the double escaping.
@dawehner's and @joelpittet's idea about testing existing checked routes that are already tested for double escaping.
Duckpatch drupalGet/drupalPost methods in simpletest to check for double escaping on pages.
Potentially a more permanent fixture could be possible.
Once Classy extends from Stable it should not reference assets/templates/etc. from core modules.
Once we have all the templates and CSS library assets in Stable, anyone using Stable or Classy as a base theme should use the Stable or Classy namespace (depending) when they are extending templates or overriding libraries.
If we don't do this, then Classy and people working from Classy or Stable will be much more likely to extend core module templates and set themselves up for things breaking when we change those core templates later.
Bad:
{% extends "@block/block.html.twig" %}Good:
{% extends "@stable/block/block.html.twig" %}The changes required should be non-disruptive and are part of proper completion of the parent issue, which is tagged as rc target.
Update templates and .info.yml files. We can work on a combined patch while waiting for the parent.
We will need to ensure that a child theme can override library assets that a parent theme has overridden via libraries-override.
Patch
Review
n/a
n/a
n/a
After updating from 7.36 to 7.37, when I try to add content, drupal reports no content types, even though there are 5 to 10 content types defined, two to seven of which are in use different sites). This is for a multilingual site (also did i18n update same day - may 8, 2015) that is on an aegir (BOA latest stable 2.4.2) self-maintained platform.
The exact error message is: You have not created any content types yet. Go to the content type creation page to add a new content type.
The content types do exist, the content exists, but trying to add content does not work due to the above error.
Something is very wrong here. What info/ logs can I provide that will help to localize the problem?
Best,
Ed
When Drupal\Core\Render\Renderer processes lazy builders the type defaults are already loaded, so any element with a #type property will not be rendered properly.
I haven't yet dived into the issue that implemented lazy builders, but this seems like a plain bug to me, not a documentation issue.
As we know, the phpunit <-> simpletest integration is problematic.
Let's start to plan how we can use the phpunit test runner only.
First step: Don't run the tests in the UI but show just a code you can use in your shell to run it.
run-tests.sh is a PHP script rather than a shell script, however since it is not intended to be run by the HTTP server, naming it "run-tests.php" is not a good idea.
Since it can not be directly executed (./run-tests.sh) and having a shebang is not desirable, it should not be set executable.
run-tests.sh is set executable in both the 6.x-2.x-dev and 7.x-2.x-dev CVS repositories.
Since we have already #80855: Add element #type table and merge tableselect/tabledrag into it and we are #1876712: [meta] Convert all tables in core to new #type 'table' and after that will #1876714: Remove #type 'tableselect', we need to build out our table rendering tests.
Build on our tests in Drupal\system\Tests\Theme\TableTest to include tableselect/tabledrag coverage in tests for #type table.
See Proposed Resolution.
None.
None.
Several of http://drupal.org/project/issues/search?text=table&projects=&status[]=Open, specifically:
#1876712: [meta] Convert all tables in core to new #type 'table'
#1876714: Remove #type 'tableselect'
#1876718: Allow modules to inject columns into tables more easily
Language negotiation setting variables should be migrated separately from #2166875: Migrate D6 languages.
Involved variable: language_negotiation
Possible values in D6:
This needs to be translated into the language.types yaml
Additionally we need to handle the relevant values in the {language} table: prefix and domain that used to be a language property and now are in the language.negotiation config entity (check yaml file).
In order to do that, we need to add values to the source and add a test to make sure that they get migrated.
Language negotiation settings (D6?/D7 locale -> locale). This will bring the priority given to different methods of detecting the user's language. Note: there can be multiple instances of this in D7 as user interface, content translation, and entity translation may define different methods.
More details about what options should be migrated can be found on the docs page and in the D7 API documentation.
Parent issue: #2337283: [meta] Add a composer.json file to every component (module, later)
Part of the parent parent issue: #1826054: [Meta] Expose Drupal Components outside of Drupal
Each of the \Drupal\Component\ namespaces need their own composer.json file, so that they can eventually be offered to the world as a library.
Add the LICENSE.txt, README.txt, TESTING.txt, and composer.json files from the template in this patch: https://www.drupal.org/node/2337283#comment-9706563
Verify the various dependencies of the component, so they can be included as requirements.
Add the component's directory to \Drupal\Tests\ComposerIntegrationTest:: getPaths().
Use composer validate in the component directory to make sure the composer.json file is valid.
| Task | Novice task? | Contributor instructions | Complete? |
|---|---|---|---|
| Create a patch | Instructions | ||
| Reroll the patch if it no longer applies. | Instructions | ||
| Update the issue summary noting if allowed during the rc | Template | ||
| Update the patch to incorporate feedback from reviews (include an interdiff) | Instructions | ||
| Manually test the patch | Novice | Instructions | |
| Review patch to ensure that it fixes the issue, stays within scope, is properly documented, and follows coding standards | Instructions |
Hi,
I have a problem in taxonomy module,
In vacabulary terms list when i add terms and subterms with no multiple parent (each term have a one parent) everything is ok and i can Drag and Drop terms for changing wight and when click "Show row weights" link Move icon hide and weight select field showing.
URL: /admin/structure/taxonomy/some_vocabulary_name
Term 1
- Term 1-1
- Term 1-2
Term 2
- Term 2-1
- Term 2-2
BUT when i added a new term with two parent in Relations Select Fields (Multiple parent) like below:
Term 1
- Term 1-1
- Term 1-2
- NEW TERM (Shared for term 1 and 2)
Term 2
- Term 2-1
- Term 2-2
- NEW TERM (Shared for term 1 and 2)
"Show row weights" link NOT working, And i can't drag and drop terms (drag work but not dropped).
This error displayed in chrome console:
Uncaught TypeError: Cannot read property 'relationship' of undefined
Please help me,
I searched and trying to find a solution but nothing.
Thanks a lot
So, in page.html.twig found this comments:
* Site identity:
* - front_page: The URL of the front page. Use this instead of base_path when
* linking to the front page. This includes the language domain or prefix.
* - logo: The url of the logo image, as defined in theme settings.
* - site_name: The name of the site. This is empty when displaying the site
* name has been disabled in the theme settings.
* - site_slogan: The slogan of the site. This is empty when displaying the site
* slogan has been disabled in theme settings.but I'm trying to use it in template (inside my custom theme, base theme - classy):
{{ logo }}
{{ site_name }}
{{ site_slogan }}When you upload a image bigger than the file size limit,
You get a double error
On #2603958: Location of settings.php is not provided in access denied mesage in update.php someone was complaining about the message they get when they try to run update.php and they are not logged in as user 1.
So that is a separate issue, but the patch they provided showed me that this was a message that is ***untranslated*** coming from an Exception.
It is really not OK for the update system to just let this exception message be shown. Not being logged in as user 1 is a common circumstance, and exception messages are not translated, because they're intended to be used during module development, not for end users/administrators of sites.
So we need to make sure that places like this are catching exceptions and instead putting comprehensible, translated error messages on the screen. Putting English-only developer/exception messages on the screen, in cases like this where it's a common problem and a reasonable error message is needed, is really not OK.
API page: https://api.drupal.org/api/drupal/modules%21file%21file.module/function/...
Enter a descriptive title (above) relating to function theme_file_managed_file, then describe the problem you have found:
Hello,
The code creates two html elements with duplicate id (forbiden by the w3c validator).
First, the code creates $attributes array and set the same id than the file input id :
<?php
$attributes = array();
if (isset($element['#id'])) {
$attributes['id'] = $element['#id'];
}
?>And after, it creates a div elem with this id before rendering the file input element :
<?php
$output = '';
$output .= '<div' . drupal_attributes($attributes) . '>';
$output .= drupal_render_children($element);
$output .= '</div>';
return $output;
?>So it produce two html elements with the same id.
To temporary fixe this issue, i have done a module (%module_name%) and put this code into the %module_name%.module file :
<?php
function %module_name%_theme($existing, $type, $theme, $path) {
$return = array();
$return['file_managed_file'] = $existing['file_managed_file'];
$return['file_managed_file']['function'] = '%module_name%_theme_file_managed_file';
return $return;
}
function %module_name%_theme_file_managed_file($variables) {
$element = $variables['element'];
$attributes = array();
if (isset($element['#id'])) {
$attributes['id'] = 'div-'.$element['#id'];
}
if (!empty($element['#attributes']['class'])) {
$attributes['class'] = (array) $element['#attributes']['class'];
}
$attributes['class'][] = 'form-managed-file';
$output = '';
$output .= '<div' . drupal_attributes($attributes) . '>';
$output .= drupal_render_children($element);
$output .= '</div>';
return $output;
}
?>I just change
<?php
$attributes['id'] = $element['#id'];
?><?php
$attributes['id'] = 'div-'.$element['#id'];
?>Best regards.