UI components are notoriously one of the most painful aspects of working with Magento 2.
I had some folks ask me about Magento 2's UI Component recently and realized everything I wrote about (now two years ago) has fled my head -- and I'm not sure I want to let it back in. https://t.co/Ubi9KVA1I0https://t.co/jtlTvuKEF9— Alan Storm (@alanstorm) August 28, 2018
One aspect that’s thrown me for a loop is the “magical data providers”. For example, if you look at
vendor/dotdigital/dotmailer-magento2-extension/view/adminhtml/ui_component/dotdigitalgroup_order_grid.xml you’ll see the following…
<dataSource name="order_report_grid_data_source"> <!--The data source--> <argument name="dataProvider" xsi:type="configurableObject"> <argument name="class" xsi:type="string">Magento\Framework\View\Element\UiComponent\DataProvider\DataProvider</argument> ...
But how could the
Magento\Framework\View\Element\UiComponent\DataProvider\DataProvider class be responsible for providing data to the order report grid?
The topic of Magento module security has been heating up. Here are just a few things that have happened recently:
I have some strong thoughts on the matter which I haven’t been shy about sharing in the past…
So I think a requirement that @ext_dn should impose is around proper disclosure of vulnerabilities in modules.— Max Chadwick (@maxpchadwick) November 27, 2018
Here, I want to express them in long form.
Recently I was trying update Gopherus’ FastCGI payload to clear PHP-FPM’s
security.limit_extensions value. Using Wireshark I knew I needed to edit an
However, no matter how much time I spent with Google I couldn’t find a decent explanation of the format of a
Fortunately, after going through the a
FCGI_PARAMS record byte-by-byte in Wireshark, I figured out what was going on. Here I’m documenting my findings for anyone else who finds them selves in the same shoes…
Recently I needed to do some analysis on FastCGI packets being sent to PHP-FPM.
Wireshark has a page on their wiki titled FastCGI which shows a screenshot of a pcap in Wireshark with detailed FastCGI info.
However, I couldn’t easily figure out from the wiki how to get the same details on my FastCGI pcap.
Something that’s tripped up both myself and devs that I’ve worked with is not finding Xdebug profiler files in the expected directory (
/tmp by default).
It usually goes something like this…
xdebug.profiler_enable_trigger = 1to a
?XDEBUG_PROFILE =1in the GET string.
This may be accompanied by running a sanity check, only to be accompanied by more hair pulling…
$ php -r 'var_dump(ini_get("xdebug.profiler_output_dir"));' string(4) "/tmp"
You may have a mysql import fail for any number of reasons. Most recently, I had an import fail with the following error.
ERROR 3 (HY000) at line 270457: Error writing file '/var/lib/mysqltmp/MLTmnake' (Errcode: 28 - No space left on device)
While the error implies that the disk ran out of space during import, the issue was in fact that the disk ran out of inodes.
Regardless of the reason of failure, you likely won’t want to start the import over from the beginning.
Here I’ll provide some tips for resuming the failed import.