horst

I haven't controlled this explicitly within the last PW versions, but it has or should work as expected. Have you forcedNew when creating the contain-variation? Do you know PIA? It adds own properties (contain, crop, cover) as shortcuts to the pageimages.

You need to request the page with a new session. Maybe you can embed a special page, (not the regular front end page), where you fetch the page via WireHttp? Or, a bit dirty, you name the iframe with a unique id that you check and pick up in the front page via JS and if it is detected, hide all elements you don't want to show there.

A) Do you use the core WireMail class or one of the WireMail modules? B) Regardless of that, may be there is somewhere (in config or where ever) set a CC or BCC address header?

Hey, first thing that I spotted is that you do a check if there are images, what exactly means there can be one or more images. But you also said you need exactly 4 images. So, what should the code do if there are less then 4 images available? You may do a check if it at minimum has 4 images: if (4 <= count($pages->get("/projects/")->images)) So, if you would check that there are more than 3 images available, you should use a for loop instead of the foreach loop. // iterate over first four images for($i = 0; $i < 4; $i++) : $image = $images->eq($i); ... Third thing is to get the variation. You can do it at the point where you copy the $image to the $img variable: $img = $image->width(200); // or $image->height(...) or $image->size(...)

Today I had this informational E-Mail in my inbox and simply want to share: ---------------------------------------- Hello from the staff at Let's Encrypt. On September 30, there will be a change in how older browsers and devices trust Let's Encrypt certificates, resulting in a minor decrease in compatibility. If you run a typical website, you won't notice a difference. Devices and browsers running up-to-date software will continue working fine, and we've taken steps to make sure the vast majority of older devices will too. If you run a large website, or need to support less common software (particularly non-browser software), you'll want to read about the details at: https://letsencrypt.org/docs/dst-root-ca-x3-expiration-september-2021/ In either case, no action is required from you. We're letting you know so you can provide answers to any questions your site visitors may have. Since 2015 we've served the world with 1.6 billion free certificates, each one providing security and privacy to people on the Web. It's work that's 100% funded by charitable donations since we are a nonprofit. If your company is interested in sponsorship, please email sponsor@letsencrypt.org. If you can make a donation, we ask that you consider supporting our work today: https://letsencrypt.org/donate/ Thank you. - The Let's Encrypt team ----------------------------------------

I removed the link. Refer to this thread and posts on how to use our support forums: Question that are not related to ProcessWire can be asked in the DEV forum, not in PW support forums.

Two things came into my mind, if I get it right what you are after. (not totally sure): You may create a "custom user page" as regular page after each successful registration. You only need one extra field in native user pages that stores the page id of the bundled custom user page. This way you can use the built in users and roles system for all login and access related and have all other stuff in a regular page with templates & fields of your choice including all regular api related stuff. (For accessing pages that should not be public, you also may hook into viewable etc. and check if the $user->isLoggedin() and if the $user->custom_field_id matches the id of the custom-user-page that is tried to be accessed.) ------- Regarding unique URLs I used a lot something like the following: $loginToken = bin2hex(random_bytes(30)) . md5(time()); // store this once into a dedicated field of the custom user page on registration https://www.php.net/manual/en/function.random-bytes.php I think the random_bytes already should be enough, adding a timestamp may be a bit superstitious or overanxious. ?

What is with an options array that contains a blacklist without the pipe sign? $options = [ 'blacklist' => [ '"', "\\0", "\\", "`", '=', '*', '%', '~', '^', '$', '#', '<', '>', '[', ']', '{', '}', "\r", "\n", "\t"] ]; sanitizer()->selectorValue($title, $options);

Which was the previous PW version and to which version do you want(ed) to upgrade? Are you using an upgrade module? If yes, is it up to date? Can you simply copy the latest stable wire folder via ftp or ssh to the server and disable the upgrade module with a dot in front of the directory name (if this resides in the site profile, and not under wire).

I don't know the PageTable field, but ... there are settings which lets you decide what to do when a (language supported) field (or page?) is empty: don't show or inherit default. This is in PW since 2013 or version 2.4. If it is explicitly with a single field that should be excluded if blank (and there is no setting what to do on empty languages), but the rest of the page should be rendered, at least one can define that in the rendering template file: <pseudo-code> If language not is default AND field is empty: skip output </pseudo-code>

https://lofi.cafe/

https://processwire.com/docs/selectors/operators/ https://processwire.com/docs/selectors/ https://cheatsheet.processwire.com/selectors/ id!=1234, id!=2345

? sounds good! ? All the best for you! ???

In general I would say yes. But there may be a chance you have a link pointing to a none https domain that then will fail. Using http with a https domain should work. (Often the servers forward them to https).

modules / core / process page list

Finally I got my local setup switched today. PHP 8 which needed a new apache version too, and then SSL needs to be updated, etc., etc., ... Now I need to upgrade my IDE for PHP 8 support too. ? After all I could debug and correct the WireMail-SMTP module: https://github.com/horst-n/WireMailSmtp

HI @eelkenet, I have setup a new test site today and it looks that any possible setting is working as expected from the PW image generation site. So it seems I need some more information from your setup. Especially this: what settings are you using for $config->imageSizerOptions ? what are the settings for $config->webpOptions ? how do you call the image url in your template file(s) with $image->size()->webp->url or $image->size()->url, or how? do you use an individually passed options array there? what are your settings in the .htaccess file ? Please can you provide these information as exact as possible. If you don't want to post this here you can PM me. My newly set up testing, without any settings in the .htaccess doesn't recreate any variations. It looks like this:

Whats about a #5: $pages->uncache($page) after the $database->commit(); to additionally free some memory.

Oh @Robin S, you are right. Sadly the value of $_SERVER['REMOTE_ADDR'] changes between the (remote) browser and the (local) webserver that is used by wirehttp. And if $_SERVER['REMOTE_ADDR'] is part of the session fingerprinting (what it is by default) it only matches if the browser and the webserver are on the same machine. ?

I'm not totally following what you are doing, but sessioningerprinting should not be an issue if you look at my code the post above with using php function getallheaders() This allows a complete 1:1 copy of the sended headers from the browser also through wirehttp. It includes the same UA header, same cookies, same everything. array(12) { ["Host"] string(32) "pw-change-default-language.local" ["Connection"] string(10) "keep-alive" ["Upgrade-Insecure-Requests"] string(1) "1" ["User-Agent"] string(132) "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/89.0.4389.90 Safari/537.36 OPR/75.0.3969.149" ["Accept"] string(135) "text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9" ["Sec-Fetch-Site"] string(4) "none" ["Sec-Fetch-Mode"] string(8) "navigate" ["Sec-Fetch-User"] string(2) "?1" ["Sec-Fetch-Dest"] string(8) "document" ["Accept-Encoding"] string(17) "gzip, deflate, br" ["Accept-Language"] string(35) "de-DE,de;q=0.9,en-US;q=0.8,en;q=0.7" ["Cookie"] string(166) "wire=8jfqut56c2ag66iaquvb27jdpu; wire_challenge=72ie9BYKDjbw4h0%2FhBYu1wmngAyUoA3F; wires=5u0b7v49ecudnj39bmdpat4dje; wires_challenge=TmFvvRVgTxBQYsyta4tST6yQJjkzymPd" }

What I have found out is that sending WireHttp requests as https lacks of embedding the ssl certificate things and therefor results in false responses. When I explicitly use http and NOT https, then this code seems to work fine, as it sends exactly the same headers like the browser of the logged in session does: $wire->session->set('wirehttprequestheaders', getallheaders()); $url = 'http://' . $wire->config->httpHost . '/cli.php'; $http = new WireHttp(); foreach($wire->session->get('wirehttprequestheaders') as $header => $value) { if('Host' == $header) continue; $http->setHeader($header, $value); } $response = $http->post($url); // or ->get() or send() if($response !== false) { echo '<pre>'; var_dump($response); } else { echo '<pre>'; var_dump($http->getError()); } My cli.php for testing looks like this: <?php namespace ProcessWire; include('./index.php'); if($wire->user->isSuperuser()) { echo '<pre>'; var_dump(getallheaders()); } else { die('NO ACCESS'); } I never got this timeout behave. Only false or true responses, but always within a second or less. Don't know if this is of any help.

Https instead of http? Then it should be wires_challenge with s, not wire_challenge. ?

Anything in the server logs? $config->debug on?

Hi Adrian, I'm not sure how to do it with wireHttp, means haven't used it until now. But the native header for sending cookies back to the server looks like this: GET /processwire/page/ HTTP/2 Host: www.example.com Cookie: key1=value1; key2=value2 Its a simple key=value pair list separated by semicolons send as a header. Maybe it can be done like this: $http = new WireHttp(); $http->setHeader('Cookie', $cookieList); References: https://tools.ietf.org/html/rfc6265 https://chenhuijing.com/blog/understanding-browser-cookies/

I believe the superusers session cookie has to be send with the WireHttp request for that?