Thanks! I'll keep testing this and report if I find any other bugs.

• Probe Wizard worked great.
• Tramming Wizard worked great.
• G30 worked great.
• UBL looked like it was working but at some point crashed out.

Not sure if the UBL crash was BLTouch acting up or something else. Will try some more this evening.

Confirmed today as the documentation for that configuration suggests it has no effect on the initial travel. Dug around and found there is no need for a new value, just this wizard doesn't use the existing value.

Opened #25498 which demonstrates a fix which is hopefully the right one.

Not sure this is the "correct" fix because I'm not very familiar with the code base and I mostly cribbed this from the tramming wizard which was moving safely. It fixed the problem for me though so hopefully its good to go.

Ensure Z-Probe Wizard follows probe offset logic to safely move to the probe position.

Description

The Z-Probe wizard does not currently take into account the clearance settings during its setup process to the initial probe move is moved at z = 0 leading to the nozzle dragging on the bed in some cases.

Requirements

n/a

Benefits

Ensures safe mode during Z-Probe Wizard movement.

Configurations

n/a

Related Issues

#25491

Offset XY movement during Z-Probe Wizard prep

Ensure Z-Probe Wizard follows probe offset logic to safely move to the probe position.

Fixes #25491

I see it. I'll follow up with an additional issue and pull request that clarify why I think this is a bug. Thanks.

OK, I'll try that. The wording doesn't really make any sense. Also you closed this. Should I reopen a new issue to clarify or fix the problem?

Did you test the latest bugfix-2.1.x code?

Yes, and the problem still exists.

Bug Description

The wizard moves to the center of the build plate directly after homing. Unless your build plate is perfectly flat or dips toward the middle this will drag your nozzle over the surface.

I'm using both a probe and a homing switch to avoid driving my nozzle into the bed in the rare cases where the probe doesn't deploy and my suspicion is its limited to this case because the home with a probe would have the offset of the probe. If that's the case, it might just be nice to allow some sort of travel height offset in the configuration.

Bug Timeline

No response

Expected behavior

Nozzle doesn't drag on build plate during probe wizard.

Actual behavior

Dragging over the buildpate

Steps to Reproduce

1. Start wizard
2. Observe dragging

Version of Marlin Firmware

2.1.x@2b86daa30bb4705f8369ca27dd5fe723c90ef634

Printer model

Ender 5 Pro

Electronics

BTT SKR Mini E3 and a BLTouch

Add-ons

No response

Bed Leveling

No Bed Leveling

Your Slicer

None

Host Software

None

Don't forget to include

• [X] A ZIP file containing your Configuration.h and Configuration_adv.h.

Additional information & file uploads

galetea.tar.gz

Thinking I'd be clever I set the prefix to 10 before installing, then tested while the setup script was running and everything looked fine. After the setup was finished Fusion didn't work because somehow the OS had been downgraded during the setup process to XP. Changed it again to Windows 10 and everything started working.

Definitely seemed like the setup script changed the OS version for the prefix but I didn't immediately see where skimming the file.

Fixed the test and that stray space that snuck in.

Somehow the tests are worse... There's a ton of fatal errors and failures that seem unrelated so hoping something changed elsewhere...

[HttpFoundation] Deprecate passing invalid URI to Request::create

Fixes: #47084

Passing an invalid URI to Request::create triggers an undefined code path. In PHP7 the false value returned by parse_url would quietly be treated as a an array through type coercion leading to unexpected results. In PHP8 this triggers a deprecation exposing the bug.

@stof Fixed the relevant fabbot changes.

@@ -1463,6 +1463,7 @@
      * @param bool $asResource If true, a resource will be returned
      *
      * @return string|resource
+     *
      * @psalm-return ($asResource is true ? resource : string)
      */
     public function getContent(bool $asResource = false)

Didn't touch this code so maybe should be handled else where?

[HttpFoundation] Deprecate passing invalid URI to Request::create

Fixes: #47084

Passing an invalid URI to Request::create triggers an undefined code path. In PHP7 the false value returned by parse_url would quietly be treated as a an array through type coercion leading to unexpected results. In PHP8 this triggers a deprecation exposing the bug.

[HttpFoundation] Deprecate passing invalid URI to Request::create

Fixes: #47084

Passing an invalid URI to Request::create triggers an undefined code path. In PHP7 the false value returned by parse_url would quietly be treated as a an array through type coercion leading to unexpected results. In PHP8 this triggers a deprecation exposing the bug.

Wasn't quite sure how the Changelog/Deprecation documentation was suppose to work so that is missing but should otherwise be good to go.

Fixes: #47084

Passing an invalid URI to Request::create triggers an undefined code path. In PHP7 the false value returned by parse_url would quietly be treated as a an array through type coercion leading to unexpected results. In PHP8 this triggers a deprecation exposing the bug.

| Q | A | ------------- | --- | Branch? | 5.4 | Bug fix? | yes | New feature? | no | Deprecations? | yes | Tickets | Fix #47084 | License | MIT

[HttpFoundation] Deprecate passing invalid URI to Request::create

Fixes: #47084

Passing an invalid URI to Request::create triggers an undefined code path. In PHP7 the false value returned by parse_url would quietly be treated as a an array through type coercion leading to unexpected results. In PHP8 this triggers a deprecation exposing the bug.

[HttpFoundation] Deprecate passing invalid URI to Request::create

Fixes: #47084

Passing an invalid URI to Request::create triggers an undefined code path. In PHP7 the false value returned by parse_url would quietly be treated as a an array through type coersion leading to unexpected results. In PHP8 this triggers a deprecation exposing the bug.

[HttpFoundation] Deprecate passing invalid URI to Request::create

Fixes: #47084

Passing an invalid URI to Request::create triggers an undefined code path. In PHP7 the false value returned by parse_url would quietly be treated as a an array through type coersion leading to unexpected results. In PHP8 this triggers a deprecation exposing the bug.

[HttpFoundation] Deprecate passing invalid URI to Request::create

Fixes: #47084

Passing an invalid URI to Request::create triggers an undefined code path. In PHP7 the false value returned by parse_url would quietly be treated as a an array through type coersion leading to unexpected results. In PHP8 this triggers a deprecation exposing the bug.

[HttpFoundation] Deprecate passing invalid URI to Request::create

Fixes: #47084

Passing an invalid URI to Request::create triggers an undefined code path. In PHP7 the false value returned by parse_url would quietly be treated as a an array through type coersion leading to unexpected results. In PHP8 this triggers a deprecation exposing the bug.

Basically this line doesn't track. It says you can use M203 but then the example is for M201.

https://github.com/teachingtechYT/teachingtechYT.github.io/blob/master/calibration.html#L1225-L1226

Side note, the documentation link directly above links to dozuki which has a huge warning at the top of the page that its no longer maintained.

Happy to make a merge request but I don't actually use RR I just opened the wrong tab so some direction would be appreciated to make sure I get the values right for example.

This is pretty easy to test. checkout the latest 10.1.x branch of Drupal core, add a basic D10 lando setup, install the site.

As soon as the site is finished installing you'll be greeted with a site that has not styles. inspecting the network tab you'll see 404's for all the css/js requests to the aggregated urls.

Notes:

1. This is the exact change from the change log but there was some discussion in the Drupal slack if it made sense for development systems like ddev and lando to just have the sites/*/files/ fallback on core to support any other modules that have lazy handlers. :shrug:
2. It might make sense to backport this to D9 recipe in case people like me are jumping back and forth between d10 and d9 and have the d9 recipe in their lando config while working on migration/updates.