Last articles

I've been struggling lately with PhpStorm IDE, specially when closing a big project and opening another big one, where sometimes it just hanged (if you are doing Drupal, any Drupal project might fall in this category given the amount of files).

After checking settings, I found out that I had the defaults, while my computer has 32Gb of RAM. 

If you want to play around with the options to see if it improves your experience, go to Help > Edit custom VM options....

It will open phpstorm64.exe.vmoptions where you can customize the VM options. It's important that you save the location of this file, as if your experimenting breaks PhpStorm, you want to be able to edit this outside of it.

I ended up with

-Xms4G
-Xmx8G
-Dawt.useSystemAAFontSettings=lcd
-Dawt.java2d.opengl=true
-XX:ReservedCodeCacheSize=1G
-XX:+AggressiveOpts
-XX:+UseFastAccessorMethods
-XX:+UseStringCache
-XX:+UseCompressedOops
-XX:+UseCompressedStrings

and so far looks like it's working better.

UPDATE: das-peter pointed out about ulimit too for allowed open files. I remember having set up that before because my hard ulimit command inside WSL2 shows:

$ ulimit -H -n
1048576

You can set that with 

$ ulimit -n 1048576

Last year, during DrupalCon Prague, Cristina approached me with an idea to include Dashboards in core. We met with Sascha, and since then a team emerged and we have been meeting more or less regularly defining how this would look like, and creating some proof of concepts.

What are we trying to solve?

When you log in to your Drupal site, you land on the /user page. There you can see how old your account on this site is. Useful, huh? Unless you have customized this behavior with contributed or custom modules, now you need to think about why you logged in, and go to wherever you can do what you wanted to do, which usually will take you several steps.

There's a big chance that this journey will start at the Content page, if you are a content manager or a content editor, but you might be a site builder, a site admin, or be responsible for other duties on your website. So we need a landing area where the content shown makes sense based on your recurring tasks. This is where customizable dashboards come into play.

Wearing multiple hats

Users often have multiple roles, or they might want to perform different tasks which might be unrelated to each other. The initial idea was to have a dedicated dashboard for each role.  That evolved into the idea that a user should have access to different dashboards, where groups of tasks and information might be grouped by their nature, not neccessarily by their role. You might wear your content manager hat one minute, and later you might need to perform some SEO duties.

So nothing should block you from having unlimited dashboards, and use the permissions system to give access to them to different roles.

Is this aligned with Drupal core goals?

Drupal Core Product Manager Lauri Eskola recently stated the three tracks were most efforts are concentrating in Drupal Core: 

• Reduce the time it takes for site builders to become proficient with Drupal.

• Empower site builders to deliver engaging editorial experiences.

• Reduce the cost of keeping Drupal applications secure.

Adding dashboards helps with the second track, enabling site builders to make editors´ lives easier by providing customized dashboards based on their editors´ needs. There would be benefits to the other two tracks as well. Having clear journeys on some common tasks for different roles will help site builders to become proficient in Drupal; and can reduce the cost of keeping Drupal applications secure if we surface the need for security updates on the dashboard and make it easy to get up to date with security updates or news from the Drupal project and the Drupal Association.

How to get this into Drupal core

When new ideas go into core, usually they are introduced as Experimental modules, and that's also our aim. Similar to other existing admin tools (like the content listing admin page) in Drupal core, our approach is based on progressive enhancement. This translates to:

• If you don't enable dashboard, you will be redirected to /user as of right now. Drupal core Standard profile cannot depend on an experimental module, so it won't be installed by default (for now).

• We will ship Dashboard module with default dashboards for common tasks in core. 
• If Layout Builder is also installed, you will be able to customize the layouts and blocks of those dashboards on the UI. 

How to get involved?

For now, we've been working in a sandbox, and we also have a GitHub project that contains an easy-to-evaluate site with some demo content, and triggers a Tugboat that we can use as demo or to manually test changes. Thanks to Tugboat.qa for providing that, and James for helping out setting it up!

If you want to help, we welcome you at the #dashboard channel on Drupal Slack.

Thanks to Gábor Hójtsy, Lauri Eskola and Cristina Chumillas for reviewing this blogpost.

Today I needed to rewrite some git repo commits from a very recently created repository where only I had committed, but from multiple systems with different setups; my usual setup with the proper info, another one where I didn't add the global user.email git property yet, and also added the license file from gitlab itself. So basically I had three different mail addresses and two different names associated with different commits that I wanted to unify, as that's a pretty messed up history for a very recent repo.

As I found on this question on StackOverflow about git author rewriting, that can be done with git-filter-repo tool:

For installing it, I used brew (but it's available in most package managers) with just: 

brew install git-filter-repo

So then you can use it as:

git-filter-repo --name-callback \
'return name.replace(b"oldName", bytes("newNameWithUtf8Chars", "utf-8"))' \
--email-callback \
'return email.replace(b"oldmail@example.com", b"newmail@example.com")' \
--force

After that I had to re-add the remote and git push --force. Take into account that this rewrites history, so you (and your team) might need to reclone the repo. Please plan this accordingly.

Also take into account that if the branch is protected, you might need to add permissions for allowing to push. I allowed that temporarily following Allow force push on a protected branch on Gitlab docs.