Best posts made by pfaciana

You need xdebug.remote_enable=1 if you plan to contact a debug client. Which I would suspect a lot of people would/should. However, it's not required, its just one feature of xDebug. You can still get a lot of value from xDebug even if it's turned off (which it is by default).

Also by off by default is remote_autostart. Setting xdebug.remote_autostart=1 will force xDebug to always attempt to connect to the remove client, regardless if the XDEBUG_SESSION is properly set. I actually don't believe this should be recommended for all. Most users should leave this off and use the XDEBUG_SESSION cookie instead. There are many browser plugins that can set this for you, and I should think that would be the recommended way. Remote debugging carries a large performance hit, and I've seen it cause issues in some edge cases. So I would think most people would only want that when they are actually stepping through code, and not every single time you make a request to the website. To each their own, but I felt it was important to point out just in case a reader was not familiar with what these settings do.

( Here are the all the setting if you want to read more: https://xdebug.org/docs/all_settings )

@leokhoa Thanks for the response! So my question is, can I make a script/some code in Laragon that whenever I change PHP versions, it also changes the Apache version to the one with the same VC at the same time. Like hooking on to some sort of event/trigger/publish-subscribe. Possible something in a Procfile? Not sure, just thinking out loud. I don't mind if its something that I'd hard code the versions in the script file.

@mnelson4 @leokhoa

define('WP_SITEURL', 'http://' . $_SERVER['HTTP_HOST']);
define('WP_HOME', 'http://' . $_SERVER['HTTP_HOST']);

^^^This totally works fine! I've been using it for years when migrating/switching between environments. I did try the odt-relative-urls plugin, just because I've never heard of it before, and it actually didn't work well for me. It fixed some urls, but not all of them.

However I do think its worth noting a couple things about HTTP_HOST.

1. HTTP_HOST comes from the client, so it is not necessarily reliable. In the context of ngrok, I don't really see that as a problem, but I think its worth noting in general, just in case somebody wanted to push that code to a production server. SERVER_NAME is much more reliable, but is dependent on you configuring your server config properly.
2. $_SERVER['HTTP_HOST'] will throw a notice and muck up your output for wpcli because $_SERVER['HTTP_HOST'] is not defined at the command line. If you're a developer there is a good chance you use wpcli, so you need to be aware of that. The fix is easy, you just need a conditional around your defines, but again, its just something one should be aware of.
3. This will not work for hard coded absolute paths in the database (which is what @leokhoa did note). However, the hard coded absolute paths are only for user created links in the admin and not assets and urls built by WordPress on the fly (which the majority of the urls). For those remaining hard coded absolute paths, you would want to use a database find and replace tool to strip those out. I use MigrateDB Pro a lot, and it has that feature, but I'm sure there are plenty of options out there. This is where the odt-relative-urls plugin may come in handy since its a filter instead of a constant, but I don't know that for sure as I haven't tested it.

Hi, I just found Laragon, and I decided to give a try. I've searched around, but I could not find an answer for this...

I already have applications like composer, git, heidisql, notepad++, putty, winscp, yarn installed on my machine. And for things like heidisql, notepad++, putty, winscp, etc, I've already spent a good deal time configuring them to my needs. I would really prefer Laragon to use my existing installations rather than whats in the bin directory. In other words, I would like Laragon to go to "C:\Program Files\HeidiSQL\heidisql.exe" for HeidiSQL instead of "C:\Laragon\bin\heidisql\heidisql.exe"; and so on for other applications.

How can I do this? I'm thinking maybe using symlinks from the Laragon bin to the applications directory where my installs are, but I was wondering if there was a better way. I grep-ed the Laragon directory, but I could not find how these tools are being defined by file location or where to override them. I noticed the Tools menu has a link called 'Configuration...' that opens up the Profile.tools file, but it wasn't clear to me if that would solve my problem either.

Thanks!

Currently I have been manually deleting the project directory, dropping the database and editing the hosts file, but I'm not sure that is the best way. I could write a script that does some of this, but there still is the hosts file and the cert which both require elevated privileges to modify. I'm thinking this has been discussed before, but I was not able to find a topic in the search. Can someone point me to the recommended way of deleting a project?

Thanks!

Hi, While searching the tpl files I could identify 7 template variables...

<<LARAGON_ROOT>>
<<HOSTNAME>>
<<DOC_ROOT>>
<<PROJECT_DIR>>
<<SSL_DIR>>
<<PORT>>
<<SSL_PORT>>

...but I could not find one for the Project Name. For example, if I create a new project called 'foo-bar' and my Document Root is 'C:\Laragon\www' and my Hostname Format is {name}.localhost; Then <<HOSTNAME>> becomes foo-bar.localhost and <<PROJECT_DIR>> becomes C:/Laragon/www/foo-bar; but how would I get just 'foo-bar' as a variable, i.e. <<PROJECT_NAME>> equals 'foo-bar'?

Specially my use case is that my production server (along with all my existing projects) are set up as {Document_Root}/{Client}/{Project}/public_html, So in the Apache tpl, I would like set

define ROOT "<<DOC_ROOT>>/<<PROJECT_NAME>>/<<PROJECT_NAME>>/public_html"

And while my immediate use case only needs to know what the PROJECT_NAME variable is. I do think, big picture, it would nice have the user be able to define custom variables as well. For example, I could set <<MY_PROJECT_DIR>> to already equal {Document_Root}/{name}/{name}/public_html, etc. So I could do

define ROOT "<<MY_PROJECT_DIR>>"

Thanks!

Here are the plugins/extensions from https://xdebug.org/docs/remote if interested...

• Xdebug Helper for Firefox ( https://addons.mozilla.org/en-GB/firefox/addon/xdebug-helper-for-firefox )
• Xdebug Helper for Chrome ( https://chrome.google.com/extensions/detail/eadndfjplgieldjbigjakmdgkmoaaaoc )
• Xdebug Toggler for Safari ( https://github.com/benmatselby/xdebug-toggler )
• Xdebug launcher for Opera

...You would use these as one option instead of setting xdebug.remote_autostart=1. Or you could just set the cookie manually, or by script, etc. More information on remote debugging is on that page as well.

@Athlone Yea, I'm all for doing whatever makes you happy. I was more less pointing out that options like *.new or *.lara, etc (to my knowledge) are not reserved, thus could provide a potential issue in the future. And I also thought it would be nice to let people know that if they decided to go/stay with *.dev and was not aware of potential pitfalls, it was worth noting. It drove me nuts for about a week the first time I encountered it. I had no clue what was going on and spent a good deal of time trying to track down that issue, and a little more trying to work around it. I do think using *.lara is a nice gesture.

@mnelson4 Totally! I would say that would be my recommended solution as its free and comes from the WordPress' own docs. MigratedDB Pro does have a nice GUI interface and you can automate it in your migrations between environments and automatically backup prior to find and replace, so if you already have it and/or you're not super comfortable with the command line, it's still a good option, but wpcli should be the recommended way. Thanks!

I know this is a bit old, but I thought I would add something worth considering. if a TLD is currently registered, or could be in the future, for a particular use or by an organization, some browsers (hi Firefox) force HTTP Strict Transport Security (HSTS) and will prevent you from accessing that site when using SSL. A very common use case is using *.dev TLD with a self-signed cert and trying to access your local site in Firefox for testing. Firefox will block access and not allow you to add an expectation. So for me the only proper thing to do is use one of the reserved TLD...

.example
.localhost
.local
.test

https://en.wikipedia.org/wiki/Top-level_domain#Reserved_domains
...to protect against this now, and in the future. Having said that, as long as one is aware of this, feel free to use whatever you'd like. For whatever reason I really liked *.dev, and it sucks I can't using it anymore since I need to test SSL on Firefox. I actually think what Firefox is doing is really good, but it would nice if you could add an expectation. I would just want that exception to complicated and difficult to do to make sure there is no possible way someone could naively (or accidentally) add that exception, but oh well. On to *.localhost for me

@leokhoa Wow, that would be great! Thanks so much.

I get the Warning "Your PHP Version & Apache Version are not compatible" when switching to a PHP version with a different VC (i.e. PHP 7.1 VC14 x64 to PHP 5.6 VC11 x64). So I go and get the Apache version with the correct VC and everything works great.

However, my question is, can I make a script/some code that whenever I change PHP versions, it also changes the Apache version to the one with the same VC at the same time. At present, I can not switch PHP versions without getting that warning, followed by continuous "httpd.exe" error windows. Is this normal? Am I doing something wrong? Previously I've used WampServer, and I never had to worry about different VCs, so I'm new to this type of management.

To recap, I can successfully change PHP versions (and Apache versions). Just not without warning and error windows popping up in the process when the VCs are temporarily not compatible.

Thanks!