Laragon + GRAV Update Issue

I have been setting up new GRAV sites for a few months now. After my first setup, I was so impressed with GRAV that I started converting all of my own managed sites over. And now I'm gradually migrating them to 2.x and making improvements as I go.

Anyway, I was using AMPP when I first started, and then soon discovered Laragon and immediately switched to it. It is much friendlier to work with than XAMPP or AMPP-like setups.

However, I've discovered one thing that is a little annoying. Now I like to develop my sites locally and then transfer them by zipping up the /user folder of the local copy and unzipping it in place of the online copy. For a time, during this development, I would be updating via the admin on both the online version and the local version.

Consistently, on my Laragon sites running either 1.7 or 2.x if I perform an update of the main GRAV program, the update process kicked off from the admin will delete the index.php file and not bring it back. The update will finish but never refresh the screen upon finishing because it can't without the index.php file there.

I don't know if this is a Laragon config issue or just the way the update process is set to operate.

My workaround has been to go into the site backup files (cuz we all do a full backup before updating anything, right?) and pull out the old index.php back into the root folder, and then everything works, and I see my update did, in fact, complete, as the system now shows no new updates waiting.

I didn't see anyone else talking about this in the forum here, so figured I'd make a post about it.

Running on Laragon 8.6.1 260302 [default] PHP 8.3.30 [TS] on a Windows 10 workstation and tested against GRAV 1.7.x and 2.x

Also, it doesn't seem to matter whether the site is installed directly on Laragon or is a copied install from the online install, which I don't do the later anymore for various reasons. My current process is to do a clean install to both locations, and from then on I only copy back and forth the /user folder. I recently connected a couple v2.x sites to Claude using the API key so it can read and write directly to my online sites, which will greatly reduce hoop jumping for smaller changes to the sites. Still working the kinks out of that process, though, for some reason, the A.I. can't delete files like custom.css. It can edit them but can't delete and upload a new complete version, which seems weird to me, but it's likely a setting I missed or haven't yet found. ;-)

P.S. I'm sorry to have posted this in the wrong area; I had not seen the support section of the form, as it was below the fold. :-( I posted here in my rush to add my 2 cents.

Can you create a step-by-step reproducible case, so I can test it on my Windows 11 system?

By the way, I'm using WSL with Ubuntu, a combination I very much like.

Not much to it.

Install Laragon

Create a web host folder of your choice in Laragon

Download and install GRAV

Wait for a version update from GRAV

. Log in to that site's GRAV admin dashboard

. Click the Update GRAV button to start the installation of the new update.

At the finish, the toaster card sometimes appears showing it completed; sometimes no toaster card.

The dashboard will never refresh from this point on because the index.php file is now missing.

If you refresh the browser, you get a 404 error and a blank white page.

If you restore index.php or manually extract it from the install zip to the site root folder, then refresh your browser window, the dashboard appears and does its normal refreshes and shows the update completed.

The same operation on the same site config has not problem on a cpanel hosting install. The only happens to me for sites hosted under Laragon on my Windows 10 machine.

I'm not ruling out that this could be something with my windows or Laragon config. But I got no clue what to look for at this point. So I thought I'd see if anyone else had run into this here. :-)

Let me know if you need any additional info.

Thanks for the steps, that was enough to track it down. When Grav upgrades itself it replaces each file in the site root by deleting the old one and copying the new one in, and it ignored any error from the copy. On Linux that works fine. On Windows, index.php is the file running the upgrade request, so Windows only marks it for deletion, refuses the copy onto that name, and then really deletes it the moment the request finishes. The update reports success and you're left without an index.php. It isn't Laragon specific, any Windows setup running the update from the admin should hit it.

I've fixed it for the next release (2.2.2). The upgrade now writes the new file next to the old one and swaps it in, and if Windows won't allow that either, it keeps the old index.php and logs a warning, so the site can never end up without one. The fix lives in the new package's installer, so it already applies when you upgrade to 2.2.2.

Until then, running the update from Laragon's terminal with bin/gpm selfupgrade should avoid it, since index.php isn't in use when the update runs from the command line.

https://gist.github.com/rhukster/0f2ebfdaf35d069e70903c9251ec5a51

I can't reproduce this on Windows myself, so if you have a few minutes I'd love a run of the attached check on your Laragon setup. Download this test file (see Gist above): grav-upgrade-check.php in your Grav root next to index.php, open https://yoursite.test/grav-upgrade-check.php, click "Run check", and paste the "Results to paste" block here. It tries the old and the new replace method on a couple of throwaway files, the same way an upgrade replaces index.php, and doesn't touch any of Grav's own files. Delete it when you're done.

What I expect to see: "old" shows FILE IS GONE and "new" shows replaced OK. If "old" comes out fine on your machine, then something else is removing the file, antivirus for example, and I'll keep digging.

— Andy

Wow! How fun is this? LOL OK, here are the results. (drum roll)

PHP: 8.3.30 (apache2handler, thread safe)
OS: Windows NT 10.0 build 19045 (Windows 10)
Web server: Apache/2.4.66 (Win64) OpenSSL/3.6.1 PHP/8.3.30
OPcache: off
Folder: L:\laragon\www\dr-new
Folder writable: yes
old: during={"method":"old","unlink":true,"copy":false,"last_error":"copy(L:\\laragon\\www\\dr-new\\grav-upgrade-probe-old.php): Failed to open stream: Permission denied"} after={"exists":false,"replaced":false}
new: during={"method":"new","copy_to_temp":true,"rename_over":false,"overwrite_in_place":true,"last_error":"rename(L:\\laragon\\www\\dr-new\\.grav-upgrade-probe-new.php.tmp,L:\\laragon\\www\\dr-new\\grav-upgrade-probe-new.php): Access is denied (code: 5)"} after={"exists":true,"replaced":true}

That seems to have done the trick.  I'll let you know if anything goes awry during the next update.

Thanks, that's exactly what I needed. Just to be clear, the check itself didn't fix anything; it only tried the two methods on throwaway files. Until 2.2.2 is out, an update started from the admin will still delete index.php, so stick with bin/gpm selfupgrade from Laragon's terminal for now, and you can delete grav-upgrade-check.php.

Your results confirm the diagnosis and tell me something useful. "old" is the bug: the copy is refused while index.php is in use, and the file is gone once the request ends. On "new", Windows refused the rename too, but overwriting the file in place worked. That's the last fallback the 2.2.2 installer tries, so on your setup the update will put the new index.php in place rather than keeping the old one.

For your 1.7 sites, the fix is only in 2.2.2, so keep using the command line when you update those.

— Andy

Got it! And THANKS! Nothing better than reporting an issue and getting not only a response but a fix so quickly.