When i edit the existing content and then click on 'preview' button it takes me to the content list page
while if we edit from node view page and then see preview it is working fine.
↧
Preview is not working when I edit the page content.
↧
view included in main menu changing path leads to WSOD
Here is how to reproduce
I have a view with page display at /path1
I go to main menu and add it as menu item and everything works ok
edit the view and change path to /path2
the whole site gets WSOD
drush cache-rebuild does not help
you have to go into /admin/structure/menu/manage/main
and edit the menu link and change /path1 to /path2
can't this be done automatically ?
or this only happens if the menu item is created from within view ?
a more graceful way of dealing with this would be nice
I think drupal 7 had a better way of handling this
↧
↧
Only render view if field is detected in template
Is it possible to tell a view to check the value of a field and then render if the field has the value?
Here is what I have tried.
File - views-view-unformatted--contextual_banner_node.html.twig
{{ if content.field_banner_image }
{% if title %}
{{ title }}
{% endif %}
{% for row in rows %}
{%
set row_classes = [
default_row_class ? 'views-row',
]
%}
{{ row.content }}
{% endfor %}
{% endif %}
My hope was to only have the view show up if the field_banner_image field is not empty. (notice first line of code, endif on last line}
Any help would be appreciated
↧
Drupal.tableDrag: column span calculated wrongly for custom column
Form containing three tables with "tableDrag" feature for every of them. Every row of table consists of four columns (latest - weight, which is hidden). Also, for every table manually added one extra row, containing a custom button in a single column. For this column, in last row, the colspan attribute is set to 4 to make it as wide as row is.
The logic of tabledrag.js is increasing or decreasing the values of colspan attribute for elements with tabledrag-has-colspan class, depending on initial state (show/hide the weight field), saved in cookie.
Also, an error will be produced if colspan attribute for a custom cell will not be exist.
First table of three in a form
Actually there should be 3, since weights columns are hidden. So JS logic should just decrease it by one.
Second table of three in a form
Last table in a form
Extra-row without colspan attribute
↧
Deletion of field_deleted_data_xxxxxx tables not working
We are developing in a team environment with the main DEV site hosted on Pantheon. We (devs) all do everything on our local machines, and use the Configuration Synchronization to push to DEV, then the other devs pull those changes.
The biggest issue we've run into is when we create fields locally, and that change gets cascaded to DEV and other local environs - then subsequently delete a field. I can't pinpoint the exact circumstances, but we regularly get errors when pushing the config changes to DEV after deleting a field stating that the table for the field couldn't be renamed to the field_deleted_data_xxxxx{long-hash-string} because the table already exists. And, to be clear, we don't do any config changes on DEV directly, so that's not the reason for things getting out of sync.
The way I understand it, after deleting a field, there's a cron job that deletes the data contained therein (in relatively small batches to keep from hitting the php timeout), and when the field_deleted_data_xxxxxx table is empty, it is deleted (dropped) as well. That process is not working. This is currently a dev site, which means we rarely have more than 2 or 3 nodes for any given content type. After deleting a field, the data should be deleted during the first cron run. However, I've run it sometimes a dozen times or more, yet the field_deleted_data_xxxxx table(s) remain.
I've marked this critical because, when this situation happens (which it does all too frequently), fixing it is difficult and time-consuming.
↧
↧
Simpletest module crashes on cleanup, uninstall
Problem/Motivation
We see: Fatal error: Trait 'Drupal\Tests\SessionTestTrait' not found See comment #10 for a stack trace.
Steps to reproduce:
- run on the Testing UI a test that ends up in a fatal error
- end up on a page like e.g.
An error has occurred.
Please continue to the error pageAn AJAX HTTP error occurred. HTTP Result Code: 200 Debugging information follows. Path: /[...]/batch?id=67&op=do_nojs&op=do StatusText: OK ResponseText: Fatal error: Call to undefined method Drupal\file_mdm\FileMetadataManager::useUri() in /[...]/modules/file_mdm_exif/src/Tests/FileMetadataExifTest.php on line 107 - click on the link to the error page
- bum: Fatal error: Trait 'Drupal\Tests\SessionTestTrait' not found in /[...]/core/modules/simpletest/src/TestBase.php on line 28
It turns out that some refactoring related to WTB->BTB conversions moved the traits required by TestBase into the core/tests/ directory, which is only autoloadable during test run-time. This means that during normal run-time those traits are not discoverable.
This also led to another issue with simpletest_clean_environment(), which similarly needs to load TestBase. During uninstall time for simpletest, PHP is unable to completely load TestBase: #2799333: Fatal error when uninstall Testing module due to traits of TestBase
Proposed resolution
For _simpletest_batch_finished():
Minimally refactor TestBase::insertAssert() to TestDatabase::insertAssert(). This is a better place for that method anyway, and TestDatabase does not require special class loading.
For simpletest_clean_environment():
Ensure that simpletest_clean_environment() loads the \Drupal\Testing namespace by calling registerTestNamespaces() on the test_discovery service.
Remaining tasks
File an issue to deprecate TestBase::insertAssert() and TestBase::deleteAssert() in favor of duplicate methods on TestDatabase.
Refactor the simpletest_cleanup*() methods into a more maintainable helper class/service: #2800267: Turn simpletest_clean*() functions into a helper class/service
User interface changes
API changes
Data model changes
↧
Add support for Quick Edit to the Content Moderation module
Problem/Motivation
At the moment, Content Moderation and Quick Edit are incompatible. If users are viewing a moderated entity, Quick Edit is only available on the default revision, which goes against Content Moderation's workflow of always editing the live revision. This can lead to tricky problems and bugs.
For example, enable moderation on an entity bundle, publish a draft, then create a new draft of that entity. If you visit the default (published) revision and use Quick Edit, the draft is discarded as Quick Edit is only aware of the default revision of any given Entity! This is really confusing for content editors (and may be considered a bug).
Proposed resolution
There are a number of steps that need to happen to make these modules work together:
- Use the EntityRevisionConverter to pass the correct Entity revision to Quick Edit paths, in the same way Content Moderation currently handles Entity Forms.
- Ensure that Contextual Links display on the latest revision of a Node. Otherwise Quick Edit will be inaccessible to users.
- Make sure that the ModerationStateWidget does not interfere with Quick Edit operations.
- Disable Quick Edit on non-latest revisions of moderated entities.
Remaining tasks
Review the provided patch.
User interface changes
None.
API changes
Quick Edit routes provided by inline editors will need to set the route option "quickedit_entity_route: TRUE" so that Content Moderation knows to swap what revision is provided for moderated Entities. This was an explicit way to add this support, as Quick Edit routes are not required to share any similarities and the alternative would be to hard-code routes (see my Workbench Moderation patch from #2749503: Add basic support for Quick Edit).
Data model changes
None.
↧
Optimize user_view('compact') in template_preprocess_node()
template_preprocess_node() does :
$variables['user_picture'] = user_view($node->account, 'compact');
(was introduced with #1292470: Convert user pictures to Image Field, that was a theme('user_picture') before that)
So on a listing page displayed with entity_view_multiple(), that's 10 independent entity_view() (sometimes on the same user), that all add up. From my benchmarks in #1852966: Rework entity display settings around EntityDisplay config entity, that's something like a -4% perf hit (I benchmarked the patch over there, though not HEAD)
We could probably mitigate a large part of this if those isolated user_view() calls could be grouped in one user_view_multiple().
↧
RevisionLogEntityTrait is not compatible with new show_revision_ui option
ContentEntityForm::addRevisionableFormFields does not recognize log message form element added by RevisionLogEntityTrait because its name is revision_log_message not revision_log as expected.
↧
↧
Accessing nodes via REST does not work.
Clean install of Drupal 8.2.4, created couple of taxonomy terms and nodes, trying to access one of them via node/3?_format=hal_json results in this:
// 20161217132819
// http://localhost/~peterla/drupal/node/3?_format=hal_json
{
"message": ""
}The very basic feature does not work at all. Tried to install the REST UI module, change to config to allow all formats and authentication methods, however, result is the same.
↧
ImageItem presave() depends on a non-existent "entity" property
While running a Drupal 7 to Drupal 8 migration, if there is an image field involved, you will get the error:
Error: Call to a member function getFileUri() on a non-object in /var/www/docroot/core/modules/image/src/Plugin/Field/FieldType/ImageItem.php, line 318
$image = \Drupal::service('image.factory')->get($this->entity->getFileUri());
This line is executed when there so no height or width defined after the parent:presave(), and so assumes we need a new Image entity.
But the "entity" property of $this is never there, at least at this point. Even when we have a valid image entity, when just saving an image with an image field normally, the "entity" property never exists.
We need another way to get the file URI, or another way to create the image entity.
↧
Move locale.translation_status state key to a separate key/value collection
Problem/Motivation
Tests in #2575105: Use cache collector for state show that this state key can easily become the largest state key, in two projects, it is 50% of the data in state.
It is also a a perfect use case for using its own collection. it is data that is only needed in rare cases in the backend, we store a list of data per project, so it is its own list and we have API's to store data per-project, which means it is a big overhead to load everything and save everything again for every project we update.
Proposed resolution
Migrate the data to a separate key_value collection and store it per project.
Remaining tasks
User interface changes
API changes
Data model changes
↧
Upload progress w/PHP 7 (& recommendation on status report)
Note: This issue summary is out of date and should be updated for the discussion so far on the issue.
The D8 status report still recommends installing PECL uploadprogress library (http://pecl.php.net/package/uploadprogress) which doesn't work on PHP 7 and seems effectively dead/deprecated. There is an issue on support for PHP 7 (https://www.drupal.org/node/2454439) which was marked fixed without addressing the uploadprogress that was mentioned in the comments. I've searched and don't see anything else on the topic so I'm opening a new issue to track it. At a minimum, the status report should be changed not to recommend PECL uploadprogress. Even better, we should have a recommended approach whether that be APC (also currently mentioned on the status report) or something else. As a reminder, Ubuntu 16.04 now ships w/PHP7 (as has been mentioned in other issues) so this is about to become more important and it would be nice to get ahead of the curve if possible.
↧
↧
Block place region breaks theme by adding margin to page top
Problem/Motivation
Markup added by block place module, specifically the div with the class 'block-place-region' is adding margin to the top of the site in Bartik theme which creates the appearance that there is a bug in toolbar. It's reasonable to assume that this will be the case in other themes as well.
In the case of Bartik this is because it styles body with a background color of #292929 (almost black). The margin top on the first div with the class block-place-region 'pushes' the region down revealing the dark background, which looks broken.
Proposed resolution
I *think* this can be solved by adding the following:
.block-place-region:first-of-type {
margin-top: 0;
}Which removes the margin top but only from the first div with that class (tested with chrome inspector).
Remaining tasks
Add css
User interface changes
No more black bar between toolbar and header.
API changes
none
Data model changes
none
↧
Store revision id in originalRevisionId property to use after revision id is updated
Problem/Motivation
After calling $entity->setNewRevision(TRUE) we have no way of knowing what revision id the entity used to be.
Considered a blocker for #2640496: Revision ID in {node} and {node_revision} can get out of sync which is critical.
Proposed resolution
Set the revision id to an originalRevisionId property in __construct
Update the originalRevisionId on post save
Return the property with getOriginalRevisionId() method
Remaining tasks
Review
User interface changes
none
API changes
Two methods added to ContentEntityBase and ContentEntityInterface
Data model changes
None
(Blocking #2809123: Reverting a revision doesn't keep moderation state)
↧
Update Symfony components to ~3.1
Problem/Motivation
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.
Proposed resolution
Prepare Drupal core to use Symfony 3.
Remaining tasks
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.
User interface changes
None
API changes
Hopefully none
Data model changes
Not yet
↧
Update the module descriptions on the Extend page
Problem/Motivation
The description of a module on the Extend page, describes what the module does.
Not all module descriptions on the Extend page follow the common format, as described in the Help text standard.
Proposed resolution
Change the module descriptions in the modules .info.yml files so that they are correct, consistent, and follow the same format.
Remaining tasks
- Compare the module description text of each module with its help text. The help texts have already been reviewed and generally the beginning of the About section provides a good wording of what the module does.
- Check the format of the description text. Does it
- start with a verb, third-person singular (Does, Provides, etc.);
- is it short and concise;
- does it end with a full stop (.)?
User interface changes
This is a UI text change.
API changes
None.
Data model changes
None.
↧
↧
No need to specify operator for Vocabulary filter in Term source
Specifying IN breaks the migration when you only provide one vocab. Error something like:
Invalid argument supplied for foreach() Condition.php:227 [warning]
Migration failed with source plugin exception: SQLSTATE[42000]: Syntax[error]
error or access violation: 1064 You have an error in your SQL syntax;
check the manual that corresponds to your MariaDB server version for
the right syntax to use near '))
ORDER BY td.tid ASC' at line 2: SELECT DISTINCT td.*
FROM
@taxonomy_term_data td
WHERE (td.vid IN ())
ORDER BY td.tid ASC; Array
(
)↧
Exception when adding tab to a node managed by content moderation
Problem/Motivation
I built a small module (see https://gist.github.com/rachellawson/36f7c8d99085d98ab561a263834ac304) that adds a new tab to content. It has a _custom_access function to determine whether it should be shown and, for some reason, only when content moderation is enabled and in use, creates the exception below:
The website encountered an unexpected error. Please try again later.
TypeError: Argument 1 passed to Drupal\content_moderation\ModerationInformation::isModeratedEntity() must implement interface Drupal\Core\Entity\EntityInterface, string given, called in /var/www/drupalvm/web/core/modules/content_moderation/src/Plugin/Menu/EditTab.php on line 81 in Drupal\content_moderation\ModerationInformation->isModeratedEntity() (line 37 of core/modules/content_moderation/src/ModerationInformation.php).
Drupal\content_moderation\ModerationInformation->isModeratedEntity('12336') (Line: 81)
Drupal\content_moderation\Plugin\Menu\EditTab->getTitle()
call_user_func_array(Array, Array) (Line: 174)
Drupal\Core\Menu\LocalTaskManager->getTitle(Object) (Line: 323)
Drupal\Core\Menu\LocalTaskManager->getTasksBuild('social_commentary.social_comment', Object) (Line: 358)
Drupal\Core\Menu\LocalTaskManager->getLocalTasks('social_commentary.social_comment', 0) (Line: 94)
Drupal\Core\Menu\Plugin\Block\LocalTasksBlock->build() (Line: 203)
Drupal\block\BlockViewBuilder::preRender(Array)
etc ...
Steps to reproduce include having code to add a tab as above. Once enabled and a content type including a field_facebook_comment boolean field is included, visiting content *seems* to be fine *until* a new draft is added and then published. Visiting the social tab then causes the exception.
Obviously, the exception is not apparent when content moderation is not enabled on the content type.
↧
theme_disable() allows the default theme to be disabled
Problem/Motivation
The theme_disable() function is used to disable one or more themes and has a check which prevents you from disabling the default theme. The check is broken and allows a default theme to be disabled.
Note that since Drupal does not present the "disable" link on the appearance page for a default theme, the only way a user would encounter this issue is if a module invoked it manually. I discovered this myself when I wrote an update hook that disabled a bunch of themes using this API function.
Proposed resolution
Fix the broken line of code.
Remaining tasks
None
User interface changes
None
API changes
None
Data model changes
None
↧
