Hello,
I am using the entity reference autocomplete field setup for custom blocks and after upgrading from Drupal 8.1 to 8.2 it no longer works, it doesn't return anything (the ajax request returns []).
Reverting my site to Drupal 8.1 fixes the issue.
The functional tests based on BrowserTestBase are failing when testing against an environment with SSL self signed certificate.
Example:php run-tests.sh --all --url https://drupal.localhost
GuzzleHttp\Exception\RequestException: cURL error 60: SSL certificate
problem: self signed certificate (see
http://curl.haxx.se/libcurl/c/libcurl-errors.html)
The error occurs when the test performs a http request, like drupalGet() using the default Http Client, in this case Guzzle that is instantiated with the option'verify' => TRUE, blocking requests to non-valid SSL certificates.
We should avoid to check the SSL certs for tests, as the comment of @boombatower in the same issue of D7:
"Https is just a transfer protocol and shouldn't effect the tests or the results unless https it self is broken."
Use the option 'verify' => FALSE (Guzzle doc reference) when instantiate the Http Client on BrowserTestBase test case.
If Adbloсk enabled and View has machine name (view_id or display_id) like a "banner", "baner", "baner_lol_lol", that part of the administration functions (on page /admin/structure/views/view/VIEW_ID/edit/DISPLAY_ID) will not work. Example, preview mode.
Reproduce:
Proposed resolution:
Maybe documentation?
In #2810381: Add generic status field to ContentEntityBase we're looking to make the status field, used for published/unpublished status on nodes and comments more generic. Although there is currently no generic interface for this.
Introduce EntityPublishedInterface and name use of it in NodeInterface and CommentInterface
Busy sites that use a lot of forms can make a lot of entries in the cache_form table. This is particuarly true of sites using Ubercart, Commerce, or other modules like Fivestar, Ideal Comments, or Hierarchical Select.
This is a very common problem which I have seen cause problems for my clients, especially when database replication is involved. A search shows how widespread the issue is: https://www.google.com/search?q=cache_form%20big
The cache_form table is truncated via cron, in system_cron. The default expiry for cache_form entries is 6 hours, hardcoded in form_set_cache.
By changing $expiry = 21600; from a hardcoded variable to variable_get('cache_form_expiry', 21600);, users can choose how often entries are pruned from cache. With shorter lifetimes, the form_cache table will be truncated more often, and will not grow as large.
I would suggest making the default expiry one hour, rather than 6, also.
None, subject to community review (especially of the comment).
None.
None.
#226728: Temporary cache table entries are not flushed
#1694574: drupal_process_form() deletes cached form + form_state despite still needed for later POSTs with enabled page caching
Back in #2448357: Config entity forms need to have access to an updated entity object at all times (committed in March 2015 as 1c72fda) an #after_build callback was introduced entity forms to update $this->entity with the input values when the form is being rebuilt and input is being processed.
The callback is being explicitly unset in ContentEntityForm. The reasoning is given in the code
+ // Content entity forms do not use the parent's #after_build callback
+ // because they only need to rebuild the entity in the validation and the
+ // submit handler because Field API uses its own #after_build callback for
+ // its widgets.
However, WidgetBase::afterBuild() does not update $this->entity. This leads to inconsistent behavior between config and content entities, in particular when dealing with Ajax.
Try removing the unsetting of the #after_build and see what breaks.
Following things have been identified:
OptionsWidgetBase massages the form values - which might be just a string for the entire widget (i.e. all deltas) - into the proper array structure in a #element_validate callback. This leads to ::massageFormValues() being called with a string as the first argument which fatals (because the #after_build callback leads to ::massageFormValues() being called prior to validation. List logic cannot be moved into a #value_callback because then FormValidator::performRequiredValidation would complain that the value (which would be an array then) is illegal.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.
Change the module descriptions in the modules .info.yml files so that they are correct, consistent, and follow the same format.
This is a UI text change.
None.
None.
The "Moderation state entities" title makes no sense for everyday administration.
I have a few ideas I'd like to throw out there for the future direction of Drupal. I decided against separate issues for each item for the sole purpose of collecting the thoughts in one place and branching out from here. (Some ideas might mature, others might not)
The more I deal with data within Drupal from a content management standpoint, the more apparent it becomes that Drupal needs to make a bit of a shift in how it presents entities.
Currently, we have the primary core entities: Node, User, Taxonomy, Comments, Forms and Blocks.
My issue with is that the demand for data structure is beginning to overpower the use cases of the core entities. There are times that I need to house a bundle of data without a public URL, so I don't need a node, but I don't need the entity exposed to the entire site, only a specific content type which means blocks don't fit either. Taxonomies don't fit the bill because the data needs to be more than just a tagging system. I don't program, so "creating my own custom entity module" is out of the question. The only current solution for a GUI based entity? ECK.
What I would like to suggest is a move away from the "old" way of doing things, and think about moving towards an ECK style approach to content within Drupal. "everything" is now (finally) an entity which brings us to a pivotal point of potentially doing away with the hard-coded core entities and moving towards an entity profile system that takes the entity as a base, and builds on it based on the desired profile. Make all entities modular, including the core entities. Obviously, certain things like users, or taxonomies will still need some core TLC and those profiles can still exist out-of-the box, but instead of having this huge elaborate block system, or node system that is baked into Drupal, a person chooses to enable the "block entity" profile, or "node entity" profile. A singular place to manage "entities" instead of segregating the entities. This would also empower module creators to leverage an import function for an entity instead of having to hard code the entity within their module. Entities could then be re-used among various modules. Import and export entities at will, regardless of the entity. There could be a repository of various entity profiles floating around where a person could look through custom defined entity templates, find the entity profile (template) that suits their needs and import it. Extend it to bundles and fields. A person finds an entity with a pre-defined bundle and fields that they can simply import into their own project, then tweak accordingly. This would also help move away from the distraction of things going everywhere... With a single place to deal with "entities", users would theoretically have an easier time dealing with entities as a whole, especially new Drupalers. Where it sits now, each and every module maintainer creates a custom entity, and it sits who-knows-where for the user to first find it, then deal with it, then remember how to create that particular entity later. I can see why new content managers have such a hard time understanding Drupal because content creation is everywhere and until you "know the lingo", you don't really understand why you use one thing over another. D8 does a better job of housing the core entities under "structure", but there are other things in there too that aren't entities and it's currently too early to tell if contribs will conform to a standard practice or go off and do their own thing.
Drupal is all about customization from the ground up. I believe it's time to remove some of the things that are still being held onto from the past, and move towards a direction where literally, anything goes. Entities should be the top of the food chain, then you create your bundles underneath it. It could even go as far as exposing properties to the user that allows the user to define "how" that entity will be used within the system. Instead of a hard coded entities like blocks, or nodes, you create an entity and tell the entity what to do, like be a node, or a block, or a term, or a form. In short, core needs to define entities, not dictate them.
Drupal does a fantastic job of internal URL's, but I think it's time to de-couple the hard-coded public facing URL from entities, and convert it into a regular field. The URL as a field, with the above thoughts on entities, and you are now presented with endless possibilities of data structure for a website. For existing entities like blocks, maybe a person wants to convert a block into a public facing page that also shows up as a regular block on other pages. Add the URL field. Maybe a person wants to create a content type that is used internally only. Remove the URL field. Extend this to Drupal handling fully custom entities, and a person could essentially create any combination of setup they need for their use-case scenario.
In addition to the hard-coded URL field becoming a regular field, I personally would love to see all hard-coded fields, become a regular field. Do away with hard-coded fields altogether unless they absolutely have to be hard-coded. I realize this is a tall order, but it goes back to the initial "entity profile" suggestion of starting with a base entity, and building any and all entities from there, all within Drupal. I have countless sites where the "author" field is completely unnecessary. Why not make it a field that can be added or removed? Why not make the "menu" a field, which can be exposed on any entity? Like I said earlier about blocks, if a person wanted a block as a page, they could add a URL field, then they could add a menu field and expose that block type as a page with its own menu link. "That's not what blocks are intended for." Since when did Drupal become dictator on how a person structures their site? Ideally, move Drupal away from the mindset of hard-coded fields, into the mindset of modular fields. Set the standard practice that hard-coded fields should only be present when absolutely necessary on very rare use-case scenarios.
A situation I ran into recently, is the Profile2 module. While great in theory, it lacks usable hard-coded fields to really pull it together. Since the author hasn't added the hard-coded field "publish", there's no way to deal with security of a particular profile or, give the convenience to the user to show or hide certain information. It has been requested that the "publish" field be added to Profile2, but this hasn't been done. If hard-coded fields became modular in nature, entities could easily become more of a template shell as opposed to a completely customized entity where the community is at the mercy of the maintainer or a coding guru.
The current implementation of the internal taxonomy URL is /taxonomy/term/[id]. Is this really still necessary now that terms are entity bundles? Vocabularies don't have an internal URL of /taxonomy/[id] and since vocabularies are technically entities and entities use the machine name instead of an ID number, there's really no reason (that I see) to have /taxonomy preceding the internal URL. The best example I can give is: Vocabs are at the same level as Content Types. Nodes don't need a special preceding URL structure like /content/node/[id], so why do taxonomy terms?
The proposal is to drop /taxonomy and simply have /term/[id]. It might also simplify things with contextual filters in views.
There might be more going on under the hood than what I understand, so forgive me if this is off base. It just seems like it's more of a backwards compatibility or legacy thing, than something that still has a valid reason.
Fieldgroup is probably one of my single most favorite modules for structuring data on a form page. However, my biggest complaint is that Drupal fiercely controls the internal properties of the core entities and forces those properties to layout in a specific place. So annoying...
I should be able to move URL within a vertical tab, or fieldset of my choosing. I should be able to do the same with menus, or promotion or any of the hard coded properties, but alas, this is impossible, even in D8, not to mention the hard-coded entity like content type, doesn't even expose the hard-coded fields to the field manager. So, this feature request really is a two-parter, 1) include field group into core and 2) make the core entity properties, actually play nice with field group. I have a feeling if hard-coded fields became regular fields, this would be easier for field group to accomplish.
In conclusion, I want to say that I feel like Drupal could be so much more, but it's still holding onto a lot of the mindsets of the past. I think it's time to break free from the "Drupal is a Blogging Platform" and recognize it for being a full on custom content management and creation platform. I hear people say "Drupal isn't a CMS, it's a CMF" except, a lot of the things Drupal still does, is more like a CMS than a CMF... Let's break the mold.
If Drupal is unable to connect to a database server as defined in settings.php, it will throw an exception like the following:
Currently, if the admin puts 'localhost' (which means to use a socket, see #23) in settings.php, and the socket doesn't exist, this exception is thrown:
PDOException: SQLSTATE[HY000] [2002] No such file or directory in /core/lib/Drupal/Component/DependencyInjection/PhpArrayContainer.php on line 83The proposal is to change the exception to:
PDOException: SQLSTATE[HY000] [2002] No such file or directory. (MySQL is configured to use "localhost" and the socket file was not found.) in /Users/cjm/Sites/drupal8x/core/lib/Drupal/Component/DependencyInjection/PhpArrayContainer.php on line 83We 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 part of: #2721129: Workflow Initiative
In this issue we will iterate on prototypes for the Trash module UI and other related changes. This issue will not include the final designs, just enough prototypes to get sign-off from a product manager, according to the core governance process.
1. map out where revision tabs should live for entity types. Which entity types need this exposed through UI (how do we decide which ones do, which ones don't?)
2. where do we put the configuration for wether to add a revision to the revision log or not. Per entity type, meaning all entity types have configuration. Where does this per entity log live?
3. What does the actual trash look like?
Gents - followed the instructions to upgrade existing Drupal 7.5 site to 8.2.0 using a few articles on Upgrade Major Version:
https://www.drupal.org/node/2350603
https://www.drupal.org/node/2257723
Ran drush cache-rebuild after that was done.
The upgrade went well, but once it was finished the site came up without any rendering with the drupal blue splash screen.
Not sure what happened here.
Simon
#1824636: Do not move the cursor to the top of the page on ajax calls solved a form focus state issue where by default the focus state comes back to the form element after rebuilding part of the form after an AJAX call. This was fixed against a select element in the views module. The problem is that it works fine on select elements and checkboxes, but not on text fields and textareas. The default AJAX event for these text fields is 'blur', meaning AJAX triggers when unfocusing, for example by clicking anywhere else or pressing tab. The problem is that that by doing so, the focus comes back on these fields by default now, making it impossible to select any other form element in the form.
I don't know if this happens anywhere in Drupal out of the box, but I included a small module to reproduce the issue. Enable ajax_test and navigate to /admin/config/development/ajax-test to see the form.
A quick example of this behaviour is shown here. The top field has an AJAX callback (the sample module has it on both, resulting in a never ending back and forth focussing between the two fields). The focus always comes back to that field:
I'm not sure what the best solution would be.
$element['#ajax']['disable-refocus'] = TRUETL.DR: the standard core upgrade procedure (remove /core and /vendor then deploy updated tarball) breaks sites when composer-installed modules/libs/depencies are installed, as parts reside in /vendor.
(or at least that's how I understood what happened - I'm not a developer and that composer thing is quite arcane so I can be wrong ;-) )
Hi.
I tried to upgrade from 8.1.3 to 8.1.6, first by just copying the files over the old ones (broke the site, restored, restarted) then by following the upgrade procedure and moving /core and /vendor first.
This broke the site again, update.php mentioned an ajax 500 error, then WSOD.
I tried via drush too and got this :
root@www:/home/www.example.com# drush up
PHP Fatal error: Interface 'CommerceGuys\Addressing\Model\AddressFormatInterface' not found in /home/www.example.com/modules/address/src/Entity/AddressFormatInterface.php on line 16
Drush command terminated abnormally due to an unrecoverable error. [error]
Error: Interface 'CommerceGuys\Addressing\Model\AddressFormatInterface' not found in /home/www.example.com/modules/address/src/Entity/AddressFormatInterface.php, line 16
Drush was not able to start (bootstrap) Drupal. [error]
Hint: This error can only occur once the database connection has already been successfully initiated, therefore this error generally points to a site configuration issue, and not a
problem connecting to the database.
Drush was attempting to connect to:
Drupal version : 8.1.6
Site URI : http://default
Database driver : mysql
Database hostname : localhost
Database port : 3306
Database username : example
Database name : example_d8
Default theme : zircon
Administration theme : seven
PHP configuration : /etc/php5/cli/php.ini
PHP OS : Linux
Drush script : /usr/bin/drush
Drush version : 8.1.2
Drush temp directory : /tmp
Drush configuration :
Drush alias files :
Install profile : standard
Drupal root : /home/www.example.com
Drupal Settings File : sites/default/settings.php
Site path : sites/default
File directory path : sites/default/files
Temporary file directory path : /tmp
Sync config path : sites/default/files/config_XXXXXXXXXXXXXXXXXXXXXXXXXXXX...
So I investigated the address module a bit closer, and found out that parts of the modules and libs (which must be installed via composer as per the module's instructions) go to /vendor and had not been replaced.
I restored the missing folders from a backup and this failed too.
I tried composer dump-autoload , then composer drupal-update ( as found in https://www.drupal.org/node/2608230 ):
composer dump-autoload
Running composer as root/super user is highly discouraged as packages, plugins and scripts cannot always be trusted
Generating autoload files> Drupal\Core\Composer\Composer::preAutoloadDump> Drupal\Core\Composer\Composer::ensureHtaccess
root@www:/home/www.example.com# composer drupal-update
Running composer as root/super user is highly discouraged as packages, plugins and scripts cannot always be trusted
[Symfony\Component\Console\Exception\CommandNotFoundException]
Command "drupal-update" is not defined.At that point I was still out of luck, so i tried to go trough the whole install for the address module again :
root@www:/home/www.example.com# composer config repositories.drupal composer https://packagist.drupal-composer.org
Running composer as root/super user is highly discouraged as packages, plugins and scripts cannot always be trusted
root@www:/home/www.example.com# composer require "drupal/address ~8.1"
Running composer as root/super user is highly discouraged as packages, plugins and scripts cannot always be trusted
./composer.json has been updated
Loading composer repositories with package information
Updating dependencies (including require-dev)
- Installing commerceguys/enum (v1.0)
Loading from cache
> Drupal\Core\Composer\Composer::vendorTestCodeCleanup
- Installing commerceguys/addressing (v0.8.2)
Loading from cache> Drupal\Core\Composer\Composer::vendorTestCodeCleanup
- Installing commerceguys/zone (v0.7.1)
Loading from cache> Drupal\Core\Composer\Composer::vendorTestCodeCleanup
- Installing commerceguys/intl (v0.7.1)
Loading from cache> Drupal\Core\Composer\Composer::vendorTestCodeCleanup
- Installing drupal/address (8.1.0-beta3)
Loading from cache> Drupal\Core\Composer\Composer::vendorTestCodeCleanup
commerceguys/addressing suggests installing symfony/intl (to use it as the source of country data)
commerceguys/addressing suggests installing symfony/form (to generate Symfony address forms)
Writing lock file
Generating autoload files> Drupal\Core\Composer\Composer::preAutoloadDump> Drupal\Core\Composer\Composer::ensureHtaccessand then I eventually updated the module :
root@www:/home/www.example.com# composer update drupal/address --with-dependencies
Running composer as root/super user is highly discouraged as packages, plugins and scripts cannot always be trusted
Loading composer repositories with package information
Updating dependencies (including require-dev)
Nothing to install or update
Generating autoload files> Drupal\Core\Composer\Composer::preAutoloadDump> Drupal\Core\Composer\Composer::ensureHtaccessOnly after this did the upgrade proceed properly :
root@www:/home/www.example.com# drush up
Update information last refreshed: Mon, 18/07/2016 - 11:52
Name Installed Version Proposed version Message
Layout Plugin (layout_plugin) 8.x-1.0-alpha22+6-dev 8.x-1.x-dev Update available
Contact Storage Export (contact_storage_export) 8.x-1.0 8.x-1.4 Update available
Panels (panels) 8.x-3.0-beta4+43-dev 8.x-3.x-dev Update available
Token (token) 8.x-1.0-alpha2+11-dev 8.x-1.x-dev Update available
YAML Form (yamlform) 8.x-1.0-beta6 8.x-1.0-beta8 Update available
Code updates will be made to the following projects: Layout plugin [layout_plugin-8.x-1.x-dev], Contact Storage Export [contact_storage_export-8.x-1.4], Panels [panels-8.x-3.x-dev], Token [token-8.x-1.x-dev], YAML Form [yamlform-8.x-1.0-beta8]
Note: A backup of your project will be stored to backups directory if it is not managed by a supported version control system.
Note: If you have made any modifications to any file that belongs to one of these projects, you will have to migrate those modifications after updating.
Do you really want to continue with the update process? (y/n): y
Project layout_plugin was updated successfully. Installed version is now 8.x-1.x-dev.
Backups were saved into the directory /root/drush-backups/example_d8/20160718095239/modules/layout_plugin. [ok]
Project contact_storage_export was updated successfully. Installed version is now 8.x-1.4.
Backups were saved into the directory /root/drush-backups/example_d8/20160718095239/modules/contact_storage_export. [ok]
Project panels was updated successfully. Installed version is now 8.x-3.x-dev.
Backups were saved into the directory /root/drush-backups/example_d8/20160718095239/modules/panels. [ok]
Project token was updated successfully. Installed version is now 8.x-1.x-dev.
Backups were saved into the directory /root/drush-backups/example_d8/20160718095239/modules/token. [ok]
Project yamlform was updated successfully. Installed version is now 8.x-1.0-beta8.
Backups were saved into the directory /root/drush-backups/example_d8/20160718095239/modules/yamlform. [ok]
The following module is missing from the file system: yamlform_node bootstrap.inc:233 [warning]
The following updates are pending:
yamlform module :
8021 - Issue #2757981: Improve YAML form node integration.
8022 - Issue #2764531: Add ownership to YAML form entity.
8023 - Issue #2765057: Remove default elements.
8024 - Issue #2765831: Improve text field autocompletion support.
8025 - Issue #2766453: Add sticky and notes to submissions.
yamlform_ui module :
8001 - Issue #2759531: Provide 'edit yamlform element custom settings' permission.
responsive_image module :
Make responsive image formatters dependent on responsive image styles.
Do you wish to run all pending updates? (y/n): y
Performing yamlform_update_8021 [ok]
Performing yamlform_update_8022 [ok]
Performing yamlform_update_8023 [ok]
Performing yamlform_update_8024 [ok]
Performing yamlform_ui_update_8001 [ok]
Performing yamlform_update_8025 [ok]
Cache rebuild complete. [ok]
Post updating responsive_image [ok]
Cache rebuild complete. [ok]
Finished performing updates. [ok]
root@www:/home/www.example.com#
Now I expect will be a recurring issue and affect other users, especially when I see this :
https://www.drupal.org/node/2608230#comment-10527890
Looks like you accidentally removed your vendor/ directory (replaced it with the tarball one?) when you did the core update.
You should only replace the core/ module instead.
This is not specific to address, I believe, as other modules use composer in the same way and will present the same issue when upgrading.
I lost 5 hours of my life today, trying to work out why on earth IE users couldn't log into our stage site. I checked session handlers, recorded network traffic, debugged the site to itty bitty little pieces.
Turns out there's a peculiar quirk in IE. Technically, underscores are not permitted in domain/host-names...at least, RFCs 952 and 1123 don't permit them. Most browsers function properly, IE even renders the page...but silently drops any cookies on that domain. Which makes logging in rather an issue.
This patch checks for the presence of underscores in the host-name, and raises a requirements warning if any underscores are present.
Rationale for addressing this issue in core:
After calling $entity->setNewRevision(TRUE) we have no way of knowing what revision id the entity used to be.
Implemented getOriginalRevisionId() to get the revision id the entity had before creating a new revision and loadUnchangedRevision() to load the revision object for the revision before a new revision was created, added them to RevisionableInterface.
(Blocking #2809123: Reverting a revision doesn't keep moderation state)
NOTE: A review of the issue queue and multiple efforts to search via Google did not turn up any relevant results to my issue. All issues that came up regarding this were from years ago and not relevant to unsupported operand types.
Running PHP 5.5.14 with Drupal 8 locally. Requirements state PHP 5.5.9 and above so I should be covered. I was receiving the below fatal error after migrating a site from D6 to D8. Sorry I don't have exact steps to reproduce, but I think the issue is a pretty clear one just reviewing the code.
Fatal error: Unsupported operand types in /Users/jessenicola/projects/jessenicola.com/docroot/core/lib/Drupal/Core/Utility/LinkGenerator.php on line 153
The code on line 153:$attributes = array('href' => '') + $variables['options']['attributes'];
As you can see, it's trying to bring two arrays together just using +, when array merge seems to really be the correct way of accomplishing this.
This code resolves the issue for me:$attributes = array_merge(array('href' => ''), $variables['options']['attributes']);
Steps to reproduce are rather prohibitive for the casual issue queue goer, but are as follows:
Menu_links migration is not working because option parameters were not found.
Verify if menu_links migration have option parameters.
We have currently an entry for simpletest as a component, but well, we are moving away from it.
Let's add a phpunit component and add a couple of people.