Leaderboard

Definitely, I will have a word with the server team and can gather the required details you need for the tutorial

That sounds like an interesting setup. I'd be very interested in a tutorial/showcase if you want and find the time ?

This is the way!

First of all, there are other benefits than performance — such as the fancy process view that SessionHandlerDB comes with (if I recall correctly, it's been a long time since I've tried it). Also if you have multiple servers but shared database, it may be easier to use DB sessions. (We use Redis in part for this reason.) I don't have any numbers, and I'm afraid those wouldn't be very helpful. Performance depends on a number of factors and thus numbers from one use case may not be applicable to another. That being said, in my personal experience for typical use cases disk is often faster and has smaller chance of running into scalability issues; I've never had scalability issues with disk based sessions, but I've run into them multiple times using database sessions. Though again, that's just my experience from the setups and use cases I've worked with ? Overall, comparing session files stored on local disk vs. MySQL/MariaDB that stores data on the same disk, I would expect database to have more overhead; it has to do much more than just read a file from the disk, after all. But then again database can make use of in-memory caching to mitigate such issues. And of course if your database is on a separate machine (or a faster disk) that would again change things, though that's also where latency due to connections and data transfer may step into the picture. Finally, the native PHP session handling mechanism is in some ways less likely to cause issues, especially compared to something you've cooked up yourself. (Just for the record, PHP has built-in support for storing sessions in Redis, so I would consider that "native"). It should probably be noted, though, that if you let PHP handle garbage cleaning, that is likely to cause some amount of overhead; the approach that Ubuntu takes (separate cron job) does not suffer from this, at least not in the same way. My personal preference for session storage is Redis — which, again in my experience, is also the fastest option of those mentioned here — and if that's not available then disk ?

It sounds like you are adding images to a PW page. Here's how you'd do that below. When you are manipulating values on a page, you usually want to have output formatting off. When that is the case, an image field will always behave as an array of images rather than 1 image. So the code below would be the same regardless of whether dealing with a single image field or a multi image field. The example also assumes your images field has the name 'images', but it can be whatever you want it to be. $page->of(false); // turn of output formatting if in template context, not necessary otherwise $page->images->add('/path/to/file.jpg or http://domain.com/path/to/file.jpg'); $page->save(); Note that $page has to exist (and have an 'id') before an file/image is added to it. So if you were creating a new Page, you'd have to do it like this: $page = new Page(); $page->template = 'name-of-template'; $page->parent = '/path/to/parent/'; $page->save(); $page->images->add('http://...'); $page->save(); If you want to delete an image, do the delete and save before adding another: $page->images->deleteAll(); $page->save(); // commit the deletion $page->images->add('http://...'); $page->save(); Or if you want to delete a specific image: $image = $page->images->first(); $page->images->delete($image); $page->save(); // commit the deletion $page->images->add('http://...'); $page->save(); Note that when you add() an image, if you are pulling from an http:// address then your PHP must support allow_url_fopen. Some web hosts have this disabled, though most don't.

When importing images to pages, make sure the page exists first. So if you are creating a new page, save it in your API code ($page->save()) before adding the image to it. Otherwise, PW won't know where to put the image(s) since the /site/assets/files/* directories are based on the page ID. If you are adding an image to a single-image field, you can just set the value of it to the URL, i.e. $page->image = 'http://www.something.com/some-image.png'; If you are adding an image to a mult-image field, you can add() it: $page->images->add('http://www.something.com/some-image.png'); Either of the above makes PW copy the image to it's assets and create the proper object. And then don't forget to: $page->save();

Hi @nabo, Many thanks for the purchase! I'll work on these; the fixes seem straightforward enough. I'll send you the updated files for testing and look to make an official release for later in the year. I hope this is OK. Thanks!

@kongondo I did indeed. The first couple definitely ended up in the ether!! ???

Hi @Krlos, Yes, Pageimage::render() is for rendering image markup from a PageImage: https://processwire.com/api/ref/pageimage/render/ In your example above, the correct call would be: <section class="about-section pt-48 pb-48" style="background-image: url(<?= $page->images->url ?>); background-repeat: no-repeat; background-size: cover; background-position: center;"> Assuming that $page->images is a single Pageimage object and not multiple images. In this case it would be: <section class="about-section pt-48 pb-48" style="background-image: url(<?= $page->images->first->url ?>); background-repeat: no-repeat; background-size: cover; background-position: center;"> This of course doesn't use srcset in any way. Going on @Stefanowitsch's example above you would need to implement Lazysizes and Lazysizes beset and then add something like <section class="about-section pt-48 pb-48" style="background-image: url(<?= $page->images->first->url ?>); background-repeat: no-repeat; background-size: cover; background-position: center;" data-bgset="<?= $page->images->first->srcset ?>"> to your markup. I'm not familiar with Lazysizes though so doubt this is a working example. If you look through this thread you can see how I implemented srcset background images using UIkit's Image component. Cheers, Chris

Very! I have tested your code (verbatim) with both Stripe and Invoice payments and emails are sent in both cases! Maybe your first one (Invoice) ended up in the ether? I am assuming you checked your junk folder.

Hi @Jan Fromm, I can confirm that this is a bug. I have it fixed in my current dev version. I am hoping to make that the next release of Padloper. I hope to do this pretty soon. Hopefully it isn't too late for your needs. Please let me know if it is. Thanks.

Does this not work equivalently for file fields?

Hello, I'm back ... I spent a week of full immersion at work. I fixed the installation error (and pulled a request on GitHub). It was a bad condition in a public function. Sorry, I had missed it. P.S. Please, check your part of read.me (more or less, at line 14) ```<?php echo buildGoogleTranslateUrl('es');?>``` Do you mean calling the function from the module as: ```<?php echo $translate->buildGoogleTranslateUrl('es');?>```

@Nishant happy to hear you have your site up and running again. Out of interest, and to help try and track this down... what version of the SessionDBHandler module were you running (if you happen to know?) are you using the MyISAM or InnoDB engine in your MySQL/MariaDB installation?

Be sure to check out the new version which has a "security" update: