<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <title>DEV Community: Yuriy Gerasimov</title>
    <description>The latest articles on DEV Community by Yuriy Gerasimov (@ygerasimov).</description>
    <link>https://dev.to/ygerasimov</link>
    <image>
      <url>https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F122173%2F9eb99f14-8380-4e87-b5f5-fe2acf3507e9.jpg</url>
      <title>DEV Community: Yuriy Gerasimov</title>
      <link>https://dev.to/ygerasimov</link>
    </image>
    <atom:link rel="self" type="application/rss+xml" href="https://dev.to/feed/ygerasimov"/>
    <language>en</language>
    <item>
      <title>PHPStorm picking up wrong index.php</title>
      <dc:creator>Yuriy Gerasimov</dc:creator>
      <pubDate>Thu, 03 Jan 2019 03:44:07 +0000</pubDate>
      <link>https://dev.to/ygerasimov/phpstorm-picking-up-wrong-indexphp-465l</link>
      <guid>https://dev.to/ygerasimov/phpstorm-picking-up-wrong-indexphp-465l</guid>
      <description>&lt;p&gt;Recently I was setting up Drupal development environment with docksal. I used traditional drupal composer setup (&lt;a href="https://github.com/drupal-composer/drupal-project"&gt;https://github.com/drupal-composer/drupal-project&lt;/a&gt;) so drupal is in the /web folder on the server.&lt;/p&gt;

&lt;p&gt;I have mapped main root folder in PHP Storm&lt;/p&gt;

&lt;p&gt;&lt;a href="https://res.cloudinary.com/practicaldev/image/fetch/s--vnJaUiX1--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://thepracticaldev.s3.amazonaws.com/i/q0wpkxd1vmcquzvtxta1.png" class="article-body-image-wrapper"&gt;&lt;img src="https://res.cloudinary.com/practicaldev/image/fetch/s--vnJaUiX1--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://thepracticaldev.s3.amazonaws.com/i/q0wpkxd1vmcquzvtxta1.png" alt="default mapping"&gt;&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;So I was really surprised when I started my debugging session and discovered some weird file being started.&lt;/p&gt;

&lt;p&gt;&lt;a href="https://res.cloudinary.com/practicaldev/image/fetch/s--68wDVGG4--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://thepracticaldev.s3.amazonaws.com/i/ut2pafm07oyw4e10jecf.png" class="article-body-image-wrapper"&gt;&lt;img src="https://res.cloudinary.com/practicaldev/image/fetch/s--68wDVGG4--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://thepracticaldev.s3.amazonaws.com/i/ut2pafm07oyw4e10jecf.png" alt="surprise"&gt;&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;Looks like PHP Storm tries to find first index.php it can find and then starts session like it is being debugged.&lt;/p&gt;

&lt;p&gt;Solution for this is to map folder "web" and actual index.php so PHP Storm can find proper file easier.&lt;/p&gt;

&lt;p&gt;&lt;a href="https://res.cloudinary.com/practicaldev/image/fetch/s--UtUTULr2--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://thepracticaldev.s3.amazonaws.com/i/lug8293x9lrv6km7yjpd.png" class="article-body-image-wrapper"&gt;&lt;img src="https://res.cloudinary.com/practicaldev/image/fetch/s--UtUTULr2--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://thepracticaldev.s3.amazonaws.com/i/lug8293x9lrv6km7yjpd.png" alt="proper mapping"&gt;&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;&lt;a href="https://res.cloudinary.com/practicaldev/image/fetch/s--khwsgKy0--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://thepracticaldev.s3.amazonaws.com/i/d5jpd5uesjslt6vqrxw9.png" class="article-body-image-wrapper"&gt;&lt;img src="https://res.cloudinary.com/practicaldev/image/fetch/s--khwsgKy0--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://thepracticaldev.s3.amazonaws.com/i/d5jpd5uesjslt6vqrxw9.png" alt="explicit index.php"&gt;&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;As result proper index.php is displayed as being debugged.&lt;/p&gt;

&lt;p&gt;&lt;a href="https://res.cloudinary.com/practicaldev/image/fetch/s--Ilhf9RM0--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://thepracticaldev.s3.amazonaws.com/i/huwhmn34zp3sz19s57jy.png" class="article-body-image-wrapper"&gt;&lt;img src="https://res.cloudinary.com/practicaldev/image/fetch/s--Ilhf9RM0--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://thepracticaldev.s3.amazonaws.com/i/huwhmn34zp3sz19s57jy.png" alt="and now nice debugging"&gt;&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;Happy debugging!&lt;/p&gt;

</description>
      <category>xdebug</category>
      <category>php</category>
      <category>phpstorm</category>
    </item>
    <item>
      <title>Automating checking your Drupal's updates with Pantheon multidev</title>
      <dc:creator>Yuriy Gerasimov</dc:creator>
      <pubDate>Sun, 16 Dec 2018 23:38:26 +0000</pubDate>
      <link>https://dev.to/ygerasimov/automating-checking-your-drupals-updates-with-pantheon-multidev-16o</link>
      <guid>https://dev.to/ygerasimov/automating-checking-your-drupals-updates-with-pantheon-multidev-16o</guid>
      <description>&lt;p&gt;Drupal updates can be very different. Some of them -- easy patches that you just roll out and forget. Some of them -- break your site. Tricky part is you never know how updates will behave on your site until you actually tried them out.&lt;/p&gt;

&lt;p&gt;This is why it is very tricky to give estimates to clients how long it is going to take. They usually do not appreciate answer 1 to 20 hours depending on some random facts.&lt;/p&gt;

&lt;p&gt;In this way rolling out updates got delayed and delayed. And then we get to situations after half a year or a year that we know for sure site will be broken after updates. And now hero time begins.&lt;/p&gt;

&lt;p&gt;Would it be nice if site would tell you not only the fact that it needs updates but also if it is going to break or not after rolling them out.&lt;/p&gt;

&lt;p&gt;Nowadays, thanks to Pantheon's multidev, it is technically possible to automate checking how your updates will behave on the site.&lt;/p&gt;

&lt;p&gt;Main idea is to regularly check updates (using drush command) then if updates are found create a separate environment and roll updates there. Afterward to ensure that they didn't break the site (at least visually) we could run some visual regression testing. So in result we have way more predictable answer about "how much efforts it will take to roll updates out".&lt;/p&gt;

&lt;p&gt;&lt;a href="https://media.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdownloads.intercomcdn.com%2Fi%2Fo%2F91467034%2Fb5b204b06ad8abbb973e55f6%2Fdiffy-autoupdates.jpg" class="article-body-image-wrapper"&gt;&lt;img src="https://media.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdownloads.intercomcdn.com%2Fi%2Fo%2F91467034%2Fb5b204b06ad8abbb973e55f6%2Fdiffy-autoupdates.jpg" alt="Updates diagram"&gt;&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;Here is a full article tutorial about how to set it up &lt;a href="http://docs.diffy.website/tutorials/put-your-sites-updates-on-autopilot-with-pantheon-multidev-and-visual-testing" rel="noopener noreferrer"&gt;http://docs.diffy.website/tutorials/put-your-sites-updates-on-autopilot-with-pantheon-multidev-and-visual-testing&lt;/a&gt;.&lt;/p&gt;

&lt;p&gt;For sure fixing smaller updates is much easier than fixing big break after year of delays.&lt;/p&gt;

</description>
      <category>drupal</category>
      <category>pantheon</category>
      <category>updates</category>
      <category>wordpress</category>
    </item>
  </channel>
</rss>
