j-w

I want to guide users from an external system to a page, passing a GET parameter and specifying the target language. We're using localized URLs, so the idea is that the external system knows only about the default language URL and prepends the language if different to default (German), making the user land on the page in the given language together with the GET parameter. As an exapmle, a German speaking user would land directly on: /meineseite/?param=value An English user will land first on /en/meineseite/?param=value, which should then get redirected to the localized URL /en/mysite/?param=value. Unfortunately the GET param gets lost during the process of redirecting. I already tried without success to hook into Session::redirect to conserve GET params. As a possible solution I see creating a page, which takes an ID of the page it should redirect to, handling the resolution of the URL according to the language while conserving the GET params. However, I see this as a not too nice workaround to my current problem. Do you have any suggestions on how I could solve my problem?

Hi there! I've also been having issues regarding "SameSite". As I'm coming different requirements I can't provide you a direct solution but only point out some things for you to check. - One thing is the session cookie ("wires"), another thing is the cookie that verifies the session ("wires_challenge"). With `ini_set('session.cookie_samesite', 'None');` you only set "SameSite" for the session cookie and not the other one. "wires_challenge" can be enabled/disabled in config.php. Have a try disabling it to see if you're still logged in after payment. If this works and you want to enable it again, then you might need to recreate it with the "SameSite" option and overwrite the previously set one. Check the code in "core/Session.php" for how this cookie is created. Unfortunately I haven't found a simpler way yet to set "SameSite" on the "wires_challenge" cookie. - If you're using ajax requests from a different domain to PW you need to use the option "withCredentials" to pass the relevant cookies. Also be sure to set any required access-control headers for cross-domain requests (I assume redirects will also require this). Hope this helps... good luck!

It's PHP 7.4.3 with Litespeed 7.6 and Zend Engine 3.4.0 (ionCube 10.4.0, OPcache 7.4.8), running ProcessWire 3.0.165. It's the same version as for the webserver.

For a worker process I need to bootstrap ProcessWire. Unfortunately somewhere in the bootstrap process the script simply exits, and I'm having problems identifying where and why. Debugging a bit I found out that somewhere during the following call in the bootstrap index.php the script is exited: echo $process->execute($config->internal); Doing a debug_backtrace in the registered shutdown function gives me only a hint to ProcessWire\{closure} Unfortunately with all php error logging on and $config->debug = Config::debugVerbose; I dont' get any more information as to why the script exits. Also tracy logs don't show anything. I already investigated if there are any culprits among the hooks but can't find anything suspicious. The script looks as follows: #!/usr/bin/php <?php namespace ProcessWire; echo "this is reached!"; include("../www/index.php"); //bootstrap ProcessWire echo "this is never reached!";

Works like a charm... thanks for that!

Because of specific requirements I need to enable basic auth, but only on a subset of URLs. For this I want to use a location directive in the .htaccess file. Unfortunately I don't manage to enforce basic auth only on specific URL. Regardless of the URL in the location directive, basic auth will be active. As a simple test I tried adding: <Location "/urlthatshouldneverevershowup"> AuthType basic AuthName "webhook" AuthBasicProvider file AuthUserFile /myauthfile Require valid-user </Location> but an access to e.g. /helloworld will automatically prompt the user/password prompt and deny access. I tried adding this directive at the beginning, at the end of www/.htaccess (which is pretty much he default PW .htaccess file) as well as in a www/site/.htaccess file, but with no success. Is there something in the PW configuration that messes with my directive? Or is there something in my directive that's wrong?