Posts made by pfaciana

Yes, that is how I read it. I'm still working on trying to integrate Laragon into my existing setup, but with how busy I am, it's just not a top priority at the moment, so I have not had a chance to try it out it. But I was thinking of just having a lookup table in the trigger.php which used the VC of the PHP version to find the full string of the matching Apache version, then fopen laragon.ini , parse it and replace the [apache] Version. However, this instance would be on a Windows machine and I have not looked into permissions. I guess I could look into having trigger-php.bat do it as well, just I haven't had time to look into it at the moment.

@leokhoa Thanks! What action triggers the host and cert clean up?

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!

I should also note, it has nothing to do with the content of the site. Could be WordPress, blank, whatever.

K, So it doesn't look like you're doing anything wrong. I did the same thing and got the same result. I tried a number of different use cases and I found a consistency with long urls, like casasemmovimento.dev. I tried some of the same length and some with less. The longer urls all had the same issue. So I don't know if this is an Ngrok issue or a Laragon issue. You may want to kick this up to @leokhoa to see if they know anything about it. However, if you don't mind, you can always try a shorter url.

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.

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 This may be an obvious question, but how do I change the Apache version inside of trigger.php? I understand that $argv will look something like this...

array(2) {
  [0]=> "trigger.php"
  [1]=> "php-7.2.8-Win32-VC15-x64" // %PHP_VERSION%
  [2]=> "httpd-2.4.27-win64-VC14" // %APACHE_VERSION%
}

...but how can I use that to tell Laragon to change the active Apache version (if applicable). I'm fine parsing the strings to get VC15 and VC14 out of them, but how would I tell Larago to change to, say, Apache httpd-2.4.34-win64-VC15? I'm only asking about the Laragon command. I'm good with the surrounding code needed.

Thanks again!

@leokhoa : Thanks! I see the the env variables and that the trigger-php.bat gets executed on PHP version change, but I could not find the command that deals with changing an Apache version. Is there a post on all the laragon commands? I only found laragon reload

(Side question: what is the recommended way to upgrade? just re-install over the existing instance?)

Thanks!

@anjoalre K, thanks, I can see that. This does not be appeared to be related to WordPress. It looks like an issue with what Laragon is serving up for https://casasemmovimento.dev.test . I'm not saying the issue, per se, is with Laragon source, just that for some reason https://casasemmovimento.dev.test is serving the default Laragon page. It could be a bug in Laragon, could be related to a user configuration. Have you upgraded recently?

If you type https://casasemmovimento.dev.test on your local machine, (so skipping ngrok for the moment), What do you see? Is it the same Laragon default page?

What does your 'sites-enabled' apache conf look like for this site?

Thanks,

Hi @anjoalre , I'm not sure if it's my ad blocker or what, but I just see the text "0_1533832129467_upload-34e40d1c-9590-44e4-b0c1-59fc01a076cf" under your post. Is there another way you can show the issue you are having with ngrok?

@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.

Oh, and one other note, since I saw it in your example. It would be best practice to always define the scheme, host and port (if necessary) when find and replacing or stripping. You can have a production/staging/dev site that handles both www.example.com site and example.com and http://example.com and https://www.example.com, etc. I typically do four find and replaces options, two with and without the www subdomain and two with and without SSL, and the replace value is the same for all of for of them. Even if you think you don't need it, it's a nice sanity check that I am not aware has any known side effects (unless of course you have a known edge case). OH, and always backup your database first!

@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.

@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.

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!