@todo from #2301317: MenuLinkNG part4: Conversion
in Menu/ViewsMenuLink::updateLink()
if ($changed) {
// @todo Improve this to not trigger a full rebuild of everything, if we
// just changed some properties.
$view->storage->save();?
Clarify what "rebuild of everything". Is that all views? The whole site?
No.
No?
All D6 Integer, Float, Decimal or Text fields are converted to Number(Integer) or Text fields in D8. These new fields don't support check boxes, radio buttons, or select lists.
When migrating Integer, Float, Decimal or Text fields we need to check the widget and use that as part of the map when figuring out which widget to use.
D8field = D6field:D6widget list_text = text:optionwidgets_select list_text = text:optionwidgets_buttons boolean = text:optionwidgets_onoff text = text:text_textfield long_text = text:text_textarea integer = number_integer:number list_integer = number_integer:optionwidgets_select list_integer = number_integer:optionwidgets_buttons boolean = number_integer:optionwidgets_onoff decimal = number_decimal:number list_float = number_decimal:optionwidgets_select list_float = number_decimal:optionwidgets_buttons boolean = number_decimal:optionwidgets_onoff float = number_float:number list_float = number_float:optionwidgets_select list_float = number_float:optionwidgets_buttons boolean = number_float:optionwidgets_onoff
We removed theme_link() #1985470: Remove theme_link() as part of a push to stop dedicating theme functions to tiny, single tag chunks of markup because it's overkill and would only get worse if we were to create a Twig template.
For links in particular, there have been many theme functions that are almost identical sort of piling up #1595614: [meta] Remove all the theme functions and templates in core that simply output a link. Replace with #type 'link' render arrays.
theme_more_link() is one of these functions that should not be converted to a Twig template.
Create #type 'more_link' that works much as #type 'link', but with a few extra default attributes set. Do not try to recreate the markup of theme_more_link() 1:1 because there is a DIV that has been deemed superfluous in the theme function that might as well be removed here (see comments #52+)
Commit patch.
Loss of wrapper divs around "more" links.
Use #type 'more_link' instead of #theme 'more_link' in renderable arrays.
Here is the current code for theme_more_link():
<?php
function theme_more_link($variables) {
return '<div class="more-link">'. l(t('More'), $variables['url'], array('attributes'=> array('title'=> $variables['title']))) . '</div>';
}
?>In order to reproduce this with #type = link, we need to make a render array with the following structure:
<?php
$more_link = array(
'#type'=> 'link',
'#href'=> 'admin/content',
'#title'=> t('More'),
'#attributes'=> array(
'#title'=> t('Show more content'),
),
'#theme_wrappers'=> array('container'),
'#wrapper_container_attributes'=> array(
'class'=> array('more-link'),
),
);
?>Issue #2301319 by pwolanin, dawehner, Wim Leers, effulgentsia: MenuLinkNG part5: Remove dead code; and party!After #2301317: MenuLinkNG part4: Conversion goes in there will be some dead code left in core - this patch just removes it.
Final chunk after #2301317: MenuLinkNG part4: Conversion. This removes the old menu_link module and dead procedural functions from menu.inc.
Follow-up to #2152261: Clean up for tablesort-indicator.html.twig
Fix the urls created for the image assets.
url() will produce /fr-ca/ or /drupal/ prefixed urls, I should have used file_create_url() for this but that doesn't exist in twig yet.
I've got a proposal started for that over at #2168231: Theme Path functions/variables needed in Twig.
In the mean time I'd like to revert part of this so that it's working.
And the best solution for this template would be #2189729: Factor out tablesort-indicator.html.twig() IMO.
Make the core template use the same pattern of building the asset file url in preprocess and pass it to the template.
Follow-up from #1984766: Change notice: Start relying on Request/Response objects for cache handling.
HTTP headers are now handed by the Symfony Request/Response objects. The legacy http header functions probably aren't doing anything. All uses of these functions need to be updated to use the objects. The functions themselves should be removed in a followup patch.
The affected functions include:
_drupal_set_preferred_header_name
drupal_add_http_header
drupal_get_http_header
drupal_page_header
drupal_send_headers
follow-up of #2211227: Refactor image and imagetoolkit: isExisting, isSupported, supportedTypes, getMimeType
While working on #2211227: Refactor image and imagetoolkit: isExisting, isSupported, supportedTypes, getMimeType, we realized that in the GD toolkit we are currently *always* loading fully an image into a GD resource. This is unnecessary overhead, as the actual GD resource is needed only if an image needs to be manipulated by applying operations to it. In most cases, $imageFactory->get() will only be needed to determine mimetype, height and width to deliver an image to the client, which can be achieved by only calling getimagesize(), and avoiding the current calls to image_type_to_extension(), imagecreatefromxxx(), and even overlaying if an image is not truecolor.
Split the logic:
ImageToolkitInterface::parseFile() only run getimagesize(), and store its results in a 'preload' property that will be used by getMimeType, getHeight, getWidth if the GD resource has not been created yetNope
One method added to ImageInterface and Image: setValid()
getItemDefinition contains a fatal error. No, seriously, look at it: buildDataDefinition is called with two arguments, it requires three. What does this say about test coverage? Do we need this method if it's not called anywhere, code or test?onChange is looking for parent which is not a defined property nor is it clear how would it be set.Followup to #1067408: Themes do not have an installation status.
Themes now undergo install and uninstall operations and maintain and installation status.
Like modules, themes must now clean up their installed configuration when they are uninstalled. We run into a few issues here.
We have a similar issue of a third-party module injecting settings into a configuration entity in #2224761: Add support for cross-field-type, extensible, extra configuration.
None.
Yes, TBD.
#1067408: Themes do not have an installation status
#2218655: Core expects $theme.settings default config file to exist
It would be cool if we had the option to provide sub directories in the /config directory for instance. Then we could structure and organise files a bit more. E.g. default views could live in /config/default_views and still be found ok.
I was thinking we could try and utilize the PHP SPL iterators and use the RecursiveDirectoryIterator, then add a Filter Iterator that filters the actual files by prefix etc...
This is kind of what I was thinking, just an initial patch. Alternatively, the other iterators could live inside the ConfigDirectoryFilterIterator too.
Please feedback. Could be crazy, I would like something like this though.
Currently forum module trying to delete taxonomy_forums field in forum_uninstall() but this field could be used in other entities. Also forum node type is not deleted when forum uninstalled so it makes sense preserve all its fields as well
Remove field deletion from forum_uninstall()
Also this removes need in calling field_purge_batch() so uninstall will be quicker.
This does not affects re-install of the forum module because forum_enable() cares to re-create all needed entities and fields
no
Spin off from #2002162: Convert form validation of users to entity validation: the definition of the roles field on user entities should use the entity_reference_field type, because it references the Role config entity.
Unfortunately this uncovers lots of bugs in entity reference handling.
This happens on a Drupal 7.26 using the default theme when previewing a comment. The ' part is equivalent to an apostrophe. What I don't know if this is something that is part of Drupal to prevent exploits or if this is a bug that should be fixed. I tried searching the Drupal.org forums if this is a bug, I wasn't able to find anything relevant.
I can't figure out how include the screenshot here, so here's a link to the screenshot: http://imgur.com/JjpRfB2.
Our translators cannot control ucfirst (capitalization).
Background: #421118: [Meta] Standardize capitalization on actions and #1496418: Views: Don't change capitalization of translatable strings with CSS
Remove the css that changes case.
Changing case displayed (not source of t() ).
No API changes.
In https://www.drupal.org/coding-standards#includes it says
When including code from the same directory or a sub-directory, start the file path with ".":
include_once ./includes/mymodule_formatting.inc
In Drupal 7.x and later versions, use DRUPAL_ROOT:require_once DRUPAL_ROOT . '/' . variable_get('cache_inc', 'includes/cache.inc');
That Drupal 7.x example will only work for code referencing the core includes/ directory. Since most people using the API documentation are not working on core, I'd imagine, it's misleading. Using DRUPAL_ROOT in one's own module requires the construction of the path from the Drupal root to the module. The equivalent ofinclude_once './includes/mymodule_formatting.inc';
isinclude_once DRUPAL_ROOT . '/' . drupal_get_path('module', 'mymodule') . '/includes/mymodule_formatting.inc';
I think you could also just dorequire_once dirname(__FILE__) . '/includes/mymodule_formatting.inc';
which is not necessarily the same absolute path but is still valid for all the issues that motivated DRUPAL_ROOT to begin with, as far as I can figure out - see #259623: Broken autoloader: convert includes/requires to use absolute paths
The pre-7.x example line in the API doc is also missing quotes and a semicolon - no great benefit to making it pseudocode versus working code, I'd think.
When enabled, at each node view the forum module will attempt a vocabulary_load() even when not necessary.
This can be avoided by moving 2 lines of code inside a if. Easy win. If we don't, we'll have the taxonomy term load operation attempted on every page that renders at least one node, even when no forum nodes at all are being manipulated.
Views currently doesn't have Context Filter support for the publishing options for nodes. Specifically the Status, Promote and Sticky fields.
I get that these are bit fields that really don't *need* context filters for the purposes of URL handling, but it would be nice to have them for things like generating summary lists that show count totals in a facet like way.
Attached is a patch that adds context filter support for these fields. Additionally I've included an exported view (in the .txt file) that demonstrates the usage of these context filters (once the patch is applied).
Lemme know if I need to make any changes to it!
When people understand that image styles control the size of their images, but want to change the defaults or create a new style, they return to the field display settings, and don't think to look under configuration. We experienced this problem in the Google Usability Study: (participant 8a)
Add a link near image styles drop-down in field display settings to the image style configuration area.
Noticed while reviewing #2301317: MenuLinkNG part4: Conversion
People who want to translate "Menus" are not going to realize they need to translate 3 different ways and enable 3 different translation modules.
Documenting now to translate Custom menu links on the menu_link_content module help page... is not a pattern we use. (We do not document how to translate nodes (articles) on the node help page. We do it on the Content translation help page... but by then, someone has already figured out to install (enable) the module, they can see the help.
Document (expose) how to enable translation for Menu Things (Menus/Configuration translation, (Plugin) menu links/User interface translation, Custom menu links/Content translation)
by:
making a general translate menu docs page on d.o
?
No?
Noticed as part of manual testing of #2301317: MenuLinkNG part4: Conversion
Custom menu link edit/add does not expose author or date. But the translation add/edit does.
?