Phpstorm Twig



  1. Phpstorm Twig Type Hint
  2. Phpstorm With Wsl

Moving from WebStorm/Phpstorm to VS Code

Complete - TwigSimpleFilter, TwigFilterFunction, TwigFilterMethod inside TwigExtensionInterface::getFilters Note not fully supported by PhpStorm, autocomplete dialog is. Full offline installer standalone setup of JetBrains PhpStorm v2020.2.1. JetBrains PhpStorm 2020 Overview. JetBrains PhpStorm is a PHP programming language development environment designed based on the JetBrains IntelliJ IDEA platform and has almost all the features of JetBrains WebStorm.

Been a user of Phpstorm/webstorm since long and wish to migrate to VS Code ? Skeptical about changing your IDE or the changes that it might bring along ? Fear not, for we will show you how you could setup VS code to be identical to Phpstorm/webstorm.

Why should you migrate to VS Code ?

I love using Webstorm/Phpstorm and it has been the editor of my choice since several years now. But here are a few advantages that I saw that compelled me try out VS Code –

  • VS Code provides the same functionality as Webstorm/Phpstorm
  • Free of cost (thanks to Microsoft for making it Open Source)
  • It is fast. (In fact, faster than Webstorm/Phpstorm and lighter in terms of RAM usage)

Lets see how to get this IDE setup

Setting Up VS Code

Firstly, you should have installed VS Code. If you haven’t, do so by downloading it from its official source

By default, VS Code does not come with out-of-the-box support for many languages like PHP, Java, Ruby, etc or even frameworks like React, Vue, Svelte, Symfony, etc. Thankfully, there are extensions to support almost every language and framework.

You will find a list of useful extensions which are highly recommended to make your new IDE function just like Phpstorm/Webstorm. In general, to keep your IDE fast, the lesser the number of extensions, the better. Consequently, only the bare essential extensions have been listed.

Recommended Extensions

1. IntelliJ Keybindings

This extension ensures your transition to VS Code to be less cumbersome by allowing you to use the same keyboard shortcuts as you did with WebStorm/PhpStorm.
There are a few exceptions but its much better than having to learn new keyboard combinations all over.

2. IntelliSense for CSS class names in HTML

As the name suggests, this adds auto-complete support for css classes in your html files.

3. Gitlens

Gitlens is a cool extension that can be used for all your git based tasks. Allows you to check a file’s history, annotate them, explore repositories, see and compare your stashed items and so on.

4. Javascript Snippets

This extension installs handy javascript snippets to speed up your development. This gives you a functionality similar to that of Live Templates in Webstorm/Phpstorm. You can also add your custom javascript snippets at ~/.config/Code/User/snippets/javascript.json

5. Extensions to Support PHP

  • Php Pack – Adds support for Php
  • Php Intellisense – Adds autocompletion and refactoring support for Php
  • Php-Debug – Adds debug support for php via XDebug

6. Extensions to Support Symfony + Twig

  • Symfony – Adds debug/autocomplete support for Symfony
  • Twig – Adds support for Twig syntax

7. Linters

Phpstorm Twig Type Hint

Highly recommended if you work with Typescript and/or Javascript.

  • TSLint – Adds support for TSLint
  • EsLint – Integrates ESLint JavaScript with VS Code

8. Docker

If you’re using docker, then this extension will be your ally. It helps you to build, manage, deploy and debug your containerized applications.

9. Reveal

This extension is the equivalent of the Select Opened File button found in PhpStorm/WebStorm. Its adds a similar button to allow you to quickly highlight an open file in the File Explorer/sidebar.

10. Code Formatting

  • Prettier – Formats Code with Prettier
  • EditorConfig – Adds EditorConfig Support for VS Code

11. Auto Rename Tag

As the name suggests, this extension will rename matching tags like <html></html> while you edit them. VS code does this automatically for html files but other file formats aren’t supported. To add support for every other format, use this extension. 32 lives download mac. I find it very helpful while using frameworks like React, Vue, Svelte or any other frameworks that use JSX or even XML files.

12. Syntax Highlighting for Apache, yaml and dotenv

  • Apache Conf – Highlights syntax for apache configuration files
  • Yaml – Adds Yaml language support
  • Dotenv – Adds support for dotenv file syntax

13. Settings Sync

Settings Sync helps you to synchronize your settings between multiple machines. Synchronizing settings has become absolutely essential for people in 2020 who are forced to toggle between work and work from home (thanks Corona!) NOTE: To sync settings, there exists a native way to do it within VS Code. I’d suggest using this recommended way instead of the extension. The extension nonetheless serves as an excellent alternate option.

14. Rest Client

Phpstorm twig autocomplete variables

If you need to test your API without leaving your IDE, this extension does a great job. Its an alternative to using Postman or Insomnia for the same.

Phpstorm

15. Improve Code Readability

  • Bracket Pair Colorizer – This extension colorizes matching brackets
  • Indent Rainbow – Makes indentation easier to read by adding colours

Bonus: Custom Vscode Icons

This extension adds custom icons for files according to their extension. For example, package.json files will have an icon with npm written on it, thus making it easier to identify the file.

Phpstorm With Wsl

Bonus Theme: Darcula IntelliJ Theme

Do you prefer Webstorm’s / Phpstorm’s Darcula theme ? If yes, then this extension is for you!

I’m sure that there are tons of other extensions available at VS code’s marketplace. Feel free to try them out and if they’re worth it, recommend them to the dev community as well.

Update VS Code Settings

Once you’ve installed all the necessary extensions, its time to update the settings of your new IDE. To open the settings, you can use the File Menu (Preferences => Settings) or you could hit Ctrl + ,. This will open up your Settings. You can tinker with the settings as you’d like.

You can also update the settings.json directly. Hit Ctrl + Shift + P and type settings.json and then select Preferences: Open Settings (JSON).

You should now have your settings.json file on the screen and could update it as shown below. And you do not need to worry about updating settings of extensions that you haven’t installed. Because, in that case, those settings will simply have no effect. So you could directly copy-paste the following settings –

Useful Keyboard Shortcuts

Here are a few new keyboard shortcuts that you might wanna learn to make your life easier.

  • Open command Palette => Ctrl + Shift + PORF1 key
  • Open Settings => Ctrl + ,
  • Select all occurrences of Find match => Ctrl + Shift + L
  • Add selection/cursor to next match =>Alt + J
  • Jump to matching bracket =>Ctrl + Shift +

To help with your transition, here’s a link to my VS Code Settings. You can most certainly use it as a reference. Also, once you finish setting up your new IDE, feel free to go through the official Tips & tricks.
Hope it helps 😉

References

Have you ever stared at your computer screen with a deer-in-headlights expression on your face thinking “I have no idea where to even start with this…”? That was me about a month ago when I was asked to help theme a Drupal 8 project for the very first time. Getting started theming in Drupal 8, still being in a fairly new iteration with a programming style differing from Drupal 7, was both an exciting and daunting task. It was exciting in the sense that I heard good things from those who’ve already started theming in D8, and daunting because there’d been a lot of changes between D7 and D8.

One of the differences between Drupal 7 and 8 is template files; PHPTemplate (.tpl.php) files were replaced with Twig (.html.twig) files. Twig is a robust and elegant template engine for PHP. Once I started working with Twig, I instantly loved it. I found it to be lightweight, fairly quick to pick up, and very readable. Not only that, but I had what felt like ultimate control to the markup, including wrapping elements and rendering exactly the ouput I needed. Often with Drupal 7, wrapping elements in a <div> requires assistance from a back-end developer.

With this newfound enthusiasm, I set out to write the best twig code ever! In order to find the output I needed, I used the Twig function dump(). This function “dumps” a variable’s information right on the screen. This proved highly useful until I realized I needed to dig deeper into the arrays and objects contained within the variable. There was only so much guess work I could do here before getting epically frustrated, seemingly wasting valuable time looking for an image file’s path.

Though there are a handful of debugging methods to choose from, I had the best luck getting what I needed by using PHPStorm to debug Twig files. That’s right, front-end friends, PHPStorm isn’t just for back-end PHP-coding devs. It can be a great tool for front-end programmers as well!

After following the steps listed in Lubomir Culen’s post about debugging Twig templates, I began to look for templates in the following path sites/default/files/php. From my understanding, opening a template folder gains access to the current template version the project is using, hence the long hash.

If a change is made to the template, an additional hash file is created and a new breakpoint will need to be set. If at any point the hash template files get overwhelming, clearing the cache (running drush cr all) will reset the PHP folder and the template files, reducing the hash files to one per template folder.

First off, I needed to acclimate myself to translating PHPStorm syntax into Twig. For example, copying a variable name in PHPStorm produces a syntax like this: $context[‘page’][‘#title’]->arguments[‘@name’]. That gets translated into the twig file like so: page[‘#title’].arguments[‘@name’]. Here’s what my PHPStorm screen looked like while working on this solution:

Some patterns and tricks I found helpful:

  • Ignoring $context and starting with the main content variable.
  • Strip array syntax, i.e. [‘page’] = page.
  • If arrays exist next to each other, separate them with periods. Ex. [‘page’][‘content’] = page.content.
  • If an array has a #, @, or other symbol associated, keep its integrity. No period is needed here. Ex. [‘page’][‘#title’] = page[‘#title’], and arguments[‘@name’] stays the same.
  • If an arrow exists, treat the method (what comes after the ->) in the same manner as arrays. Ex. [‘#title’]->arguments = [‘#title’].arguments
  • If you’re having trouble rendering the desired output, try adding .value to the end of the render code and see if that does the trick.
  • Use dump() simultaneously with PHPStorm’s suggested variable path.
  • Refer to the Twig documentation for other handy built-in features.

Up until the moment I got PHPStorm doing the heavy lifting, my team and I were relying soley on the dump() Twig function. We were halfway through the project when I discovered a value was no longer present. The disappearance was due to a template’s reliance on a value being rendered via an array placement, i.e. content.tile.3['#markup'], the ‘3’ referring to the 4th placement in the ‘tile’ array. To alleviate potential confusion, ‘tile’ happened to be the custom field group where the field_to_render existed, and the field_to_render was the 4th field in the list of fields. When a field was moved within the ‘tile’ field group, the code broke. Once I had access to the phpstorm debugger, I was able to see a better way to render this element, i.e. content.field_to_render. It suddenly dawned on me that our project needed some tidying, so I rolled up my sleeves and got to work.

These are the strategies I established during my clean-up process:

  • Create the shortest render code possible with the closest placement to the main content variable. This will be the most stable. My array placement example mentioned previously is a good example of this. The same value can be present and rendered in numerous ways.
  • If rendering a field, use this pattern: content.field_to_render. This will render the field object, inheriting any backend logic that’s been applied to that field existing in the view_mode you are theming.
  • If you prefer having just the markup or integer value, try adding a .value to the end. Examples: content[‘#node’].nid.value will provide just the node id, and content.node_title will render the title object whereas content[‘#node’].title.value will render the title as a string.
  • The first element in an array might be the most stable. For example, we often use the media module which can add complexity to a media item’s data structure. In order use a node’s image as a background for a <div>, this is the best approach we found: <div class=”banner-image”>.

Any change can be tough to navigate, but it’s often well worth the effort. My experience theming in Drupal 8 thus far has been lovely, and fairly intuitive. I find it offers front-end developers more authority over the markup than its predecessor, and makes me excited for the future of theming in Drupal 8. If you were at all daunted by the thought of theming in Drupal 8, I hope this post helps you in your future twig debugging endeavors!

Note:Devel and Kint are a couple additional tools available for debugging Twig variables, and I mention those in case others find them useful. More information on how to set those tools up for debugging Twig files (and more!) can be found in this Drupal 8 Theming Guide and on Amber Matz’s Let’s Debug in Drupal 8! post.

If you’re new to Drupal 8 theming, I would start with the resources Amber specifies in her “Editor’s notes”, and sqndr’s D8 theming docs. Debugging twig files is an intermediate topic.

If you have any personal experience with Drupal 8 theming, or insight you’d like to share, I’d love to hear about it in the comments section!

Phpstorm

Get In Touch

Questions? Comments? We want to know! Drop us a line and let’s start talking.

Learn More