Closed gwharton closed 4 years ago
Hi @gwharton, thanks for opening the issue. I've tried to reproduce the issue without success. As "test-subjects", I've used the product, the customer and the orders grid of a native Magento 2.3.4 instance with sample data. There must be some other difference in the UI component that is causing the issue.
In vendor/magento/module-ui/Config/Data.php
, in the method \Magento\Ui\Config\Data::initData()
, could you please log or somehow debug what the value of $this->cacheId
is before the record is written to the cache?
Otherwise, if you could make an example module that exhibits the problem available to me, I'm happy to look into it.
I get a call with "ui_component_configuration_data_notification_area" and then a following call with "ui_component_configuration_data_gwattachment_attachment_listing"
gw_attachment_listing is the ui component and the id matches the id displayed on the command line when i save the layout file.
I guess that info doesn't help.
I'll look to produce a dummy module which displays the issue.
The call to $data = $this->cache->load($this->cacheId); succeeds and returns cache'd data. I'll do some digging.
Watcher initialized (Ctrl-C to quit)
13:12:32 Processing /home/ubuntu/dev/app/code/Gw/Attachment/view/adminhtml/ui_component/gwattachment_attachment_listing.xml
13:12:32 Cleaning id(s): ui_component_configuration_data_gwattachment_attachment_listing
Reading app config by shelling out to php
13:12:32 Cache storage {:id_prefix , :backend Cm_Cache_Backend_File, :cache_dir /home/ubuntu/dev/var/cache}
13:12:32 cleaning file /home/ubuntu/dev/var/cache/mage--f/mage---UI_COMPONENT_CONFIGURATION_DATA_GWATTACHMENT_ATTACHMENT_LISTING
Reading app config by shelling out to php
13:16:15 Processing /home/ubuntu/dev/app/code/Gw/Attachment/view/adminhtml/ui_component/gwattachment_attachment_listing.xml
13:16:15 Cleaning id(s): ui_component_configuration_data_gwattachment_attachment_listing
Reading app config by shelling out to php
13:16:15 Cache storage {:id_prefix , :backend Cm_Cache_Backend_File, :cache_dir /home/ubuntu/dev/var/cache}
13:16:15 cleaning file /home/ubuntu/dev/var/cache/mage--f/mage---UI_COMPONENT_CONFIGURATION_DATA_GWATTACHMENT_ATTACHMENT_LISTING
Reading app config by shelling out to php
ubuntu@dev:~/dev/var$ find . -name *GWATTACHMENT*
./cache/mage-tags/mage---1e5_GWATTACHMENT_ATTACHMENT_INDEX
./cache/mage--4/mage---1e5_UI_COMPONENT_CONFIGURATION_DATA_GWATTACHMENT_ATTACHMENT_LISTING
ubuntu@dev:~/dev/var$
ubuntu@dev:~/dev/var$ grep -r GWATTACHMENT *
cache/mage-tags/mage---1e5_MAGE:1e5_UI_COMPONENT_CONFIGURATION_DATA_GWATTACHMENT_ATTACHMENT_LISTING
cache/mage-tags/mage---1e5_CONFIG:1e5_UI_COMPONENT_CONFIGURATION_DATA_GWATTACHMENT_ATTACHMENT_LISTING
cache/mage--f/mage---1e5_LAYOUT_ADMINHTML_STORE1_6427A480103B4A6A98903714E58715A33_PAGE_LAYOUT_MERGED:a:4:{s:4:"hash";s:0:"";s:5:"mtime";i:1586174976;s:6:"expire";i:9999999999;s:4:"tags";s:83:"1e5_DEFAULT,1e5_GWATTACHMENT_ATTACHMENT_INDEX,1e5_LAYOUT_GENERAL_CACHE_TAG,1e5_MAGE";}
cache/mage--3/mage---1e5_STRUCTURE_LAYOUT_ADMINHTML_STORE1_6427A480103B4A6A98903714E58715A33:a:4:{s:4:"hash";s:0:"";s:5:"mtime";i:1586174977;s:6:"expire";i:9999999999;s:4:"tags";s:83:"1e5_DEFAULT,1e5_GWATTACHMENT_ATTACHMENT_INDEX,1e5_LAYOUT_GENERAL_CACHE_TAG,1e5_MAGE";}
ubuntu@dev:~/dev/var$
Is it clearing the wrong cache location for some reason? Related to the 1e5 prefix on cache entries? I dont have a prefix set in config.
ok, I see the problem. I dont have a cache prefix set in my env.php. both are set to ''
I guess your module looks and see's that there is no prefix, but when there is no prefix set, magento uses a hash of the path to the etc folder to generate its own prefix if one is not used.
I'll add a prefix and see how I get on.
Update : Yes, after adding cache prefix to env.php, the problem goes away. Feel free to close this as the default install of magento has cache prefix's set. I removed them for ....... errrr..... some reason I don't recall.
Hi @gwharton, thanks for digging into this.
The cache id prefix isn't required - if no cache ID prefix is present in the env.php
file, the cache watcher calculates it the same way Magento does.
The :id_prefix
without a value in the log however looks like you might have been setting it to an empty string. Is that correct?
Because if you didn't have a cache prefix key in your env.php
at all, the calculation would have been applied.
Can you confirm?
Yes, I had set it to an empty string, not null, or not present at all.
'cache' => [
'frontend' => [
'default' => [
'id_prefix' => ''
],
'page_cache' => [
'id_prefix' => ''
]
]
],
In this configuration, Magento still generates a prefix of its own for cache files. I guess the bug is on magento for not using a prefix of '', but your module could work around that.
I guess not many people will be caught by this as magento config has them by default, but I noticed it had been added myself one day and set it to an empty string as I didn't need or want a cache prefix.
Interesting! :) I'll adjust the watcher to also calculate the prefix in that case, so this edge case doesn't pop up again! Thank you for your help!
Implemented check, will be included in the next release (no ETA at the moment, but some time soon I think).
It took longer than expected until I rolled a new release. Just to follow up, I pushed 1.0.28 including this change now.
When making a change to a UI Components layout file, the watcher see's that the file has changed, but the frontend does not reflect the updated config. See attached screenshot where I change the label of the ID field in the layout file.
I have to use the option (a) to clear all cache to get it to reflect the change.