• Path traversal in Clear Cache (EGSA-2026-01, CVE-2026-97164, severity 7.0). Event Gallery → Clear Cache took the name of the cache folder to empty from the request and did not check where it led. A back-end user with the permission to manage Event Gallery - in Joomla’s default permissions every Administrator, not only a Super User - could make it delete any folder the web server may write to, up to the whole site. It now only empties a folder which lies directly in the image cache.
• Cross-site scripting and open redirect on the front-end upload page (EGSA-2026-02, CVE-2026-97165, severity 5.3). The Back link of the upload page of the front end took its target from the address of the page and printed it as it came. A prepared link could therefore make it point to another web site, or run a script in the session of the editor who opened it. Affected are 3.11.4 to 6.0.0. The link now only leads to a page of your own site, and there is none when the address names anything else. If you have a template override of upload/default.php of the front end, it gets the checked target as well; take over the escaping of the link from the new file.
• Forged uploads (EGSA-2026-03, CVE-2026-100747, severity 5.1). Uploading a file did not check the security token, neither in the back end nor in the front end, so a prepared page on another web site could make a logged in editor upload a file into an event - and replace a file of the same name there. The upload now needs the token. Users who may edit but not manage Event Gallery, like a publisher who uploads from the front end, keep uploading as before. A file which is larger than post_max_size of your server is now answered with exactly that instead of a general failure.
• Forged cart changes (EGSA-2026-04, CVE-2026-100748, severity 6.9). Adding an image to the cart and removing it again were plain links without a token, so a prepared page on another web site could change the cart of a visitor. The cart requests need the form token now.
• Forged clean-up in the back end (EGSA-2026-05, CVE-2026-100749, severity 5.1). The two clean-up links on the overview page of the backend, which remove orphaned files and old carts from the database, now carry Joomla’s form token like every other action which changes data. Before, a prepared link on another website could have triggered them while you were logged in to the backend.

Hardening without a known vulnerability

• The identifiers Event Gallery gives to a cart and to an order were built from the moment they were created and from nothing else, which had two consequences. Anyone who knew roughly when an order was placed could work out its identifier; the download links of an order were never at risk, because those are protected by a separate token which is properly random, but the identifier itself was no secret. And the identifier was a 28 digit number, too large for PHP to handle as a number at all, so a single careless line in Event Gallery or in Joomla could turn every identifier into one and the same value and show one customer the order of another. New carts and orders get an identifier which begins with letters and continues with 16 random bytes, so it can neither be guessed nor be mistaken for a number. Carts and orders which already exist keep the identifier they have and keep working, links to them included; there is nothing to migrate.
• Three small backend requests - the ones which fill the list of events and images in the content plugin dialog and count the missing thumbnails on the dashboard - did not check the form token. Joomla itself only lets users who may manage Event Gallery reach them, and they only read data, so a page on another web site could not get at their answer. They check the token and the permission themselves now. Users who may manage the component notice nothing.
• Sending a test mail from an email template did not check the security token of the back end, so a prepared link on another web site could make a logged in administrator send test mails to themselves. The button now carries the token, and sending a test mail as well as rendering the preview need the permission to edit.
• The upload page printed the folder name of the event without escaping it - in its heading, and in the message about a folder name with unsupported characters, which is the one place where such characters are certain to occur. Both are escaped now. An event you save in the back end has always had its folder name cleaned, so this concerns folder names which came into the database some other way.

• Several images at once. In buy mode every thumbnail carries a tick, and one format dialog puts the whole selection into the cart. The Buy images button moved into a bar at the bottom of the page. See Buying images.
• A cart and a checkout which keep up. The cart saves every change right away, the format dialog shows what is already in the cart, and the checkout offers the payment and shipping methods as cards. See Buying images.
• PayPal Checkout. A new payment method on the PayPal API of today. A Client ID and a Secret is all it needs - no notification address, no webhook. This is the method to pick for a new shop. See Buying images.
• New mails for your buyers. Readable on a phone and on a desktop, in dark mode too, with your logo and accent colour, the ordered images in the order confirmation, a real pay button and a plain text version. See Mails.
• Mails in German, and in the language of the buyer. The mails which come with Event Gallery are available in German now, and everything in an order mail comes in the language the buyer ordered in. See Migration Hints and Bug Fixes.
• S3 storage from any provider, with several accounts. Amazon S3, Cloudflare R2, Backblaze B2, Wasabi, Hetzner and every other service with the S3 API. A connection check tells you whether your originals are really private, and a single bucket is enough. See S3 storage.
• A new upload. Every file gets its own progress and state, you can drop files onto the page, cancel and retry them, the page asks before it replaces a file, and it pauses instead of failing when your login expires. See Upload.
• Security fixes. A path traversal in Clear Cache, cross-site scripting on the front-end upload page and forged uploads, cart changes and clean-ups are fixed. See Security Fixes.

• Amazon S3: the S3 settings moved from the options of the component to S3 accounts. The update creates an account named Amazon S3 from your former options and assigns it to all existing S3 events, so your galleries keep working without any action. You find it under Event Gallery → Accounts - S3 Storage. The section Amazon S3 of the options is gone. If your thumbnail links pointed to bucket.s3.amazonaws.com, they now point to the regional host bucket.s3.<region>.amazonaws.com, which is the same bucket.
• The Braintree payment plugin is gone. It relied on Braintree’s version 2 drop-in UI, which Braintree retired, so the payment form stopped working; it had been marked as deprecated for a while. The update uninstalls the plugin if it is still present. Orders which were paid with a Braintree payment method keep loading in the backend and in the order tracking, and their payment method is still shown by its name. The method itself is no longer offered in the checkout. Remove it from Event Gallery → Methods once you no longer need it in your order history, and offer Stripe or PayPal instead.
• The PayPal Adaptive Payments payment plugin is gone. Adaptive Payments is an API PayPal shut down years ago, so the plugin could not complete a payment any more; it had been marked as deprecated in the backend for a while. The update uninstalls it if it is still present. Orders which were paid with it keep loading in the backend and in the order tracking, and their payment method is still shown by its name. Remove it from Event Gallery → Methods once you no longer need it in your order history. Use the new PayPal Checkout method instead; the plain PayPal method is unaffected as well.
• The colours of the frontend now come from one set of CSS custom properties, the --eg-* tokens declared on :root. If you overrode the private custom properties which the format dialog, the cart, the mini cart or the checkout used to declare on their own containers (--primary-color, --text-secondary, --border-color, …), those names are gone; set the --eg-* tokens instead. The FAQ has a section on customizing the colours.
• The image type selection can be turned into a selection of several images with one format dialog. The new option Buy controls on images in the cart settings decides whether the thumbnails carry the cart button, the tick for the selection, or both. Existing sites get both.
• The Buy images button no longer sits between the description and the thumbnails of an event. It lives in a bar pinned to the bottom of the page, which in buy mode turns into the selection bar with its Done button. The option Sticky Image Type Selection, which used to show the cart buttons without pressing Buy images first, is gone: the bar is always in view, and the buy mode is remembered per event while the browser tab is open. If you styled the old .orderimages-container block or its help box, that CSS has nothing to style any more; the bar is .eventgallery-buy-bar and follows the --eg-* tokens. The language keys of the removed help texts, COM_EVENTGALLERY_PRODUCT_BUY_IMAGES_SELECTION_HELP and the two USE_STICY_IMAGETYPE_SELECTION option labels, are gone as well.
• The mails to your buyers now come in German as well. Until now the mails which come with Event Gallery were English only, and a German shop had to create its own email templates. If your site has German buyers and you did not create own email templates, they get German mails after this update where they got English ones before. Own email templates win as before, also an own template for all languages.
• Email templates you created yourself keep working as they are and look like before. Mails for which you have no own template, or whose own template has an empty body, get the new design with this update. If you want the new design for a mail you customised, open its email template, press Load Default and bring your changes over. The new order confirmation no longer says that an order "usually takes 2-3 weeks"; if you want to name a delivery time, add it to your own template.
• If you have a template override of the upload page of the back end (upload/default.php of com_eventgallery in your administrator template), or an override of the upload page of the front end which copied that markup instead of including the file of the back end, bring it up to date: the upload now needs the security token, which the page hands to its script as the attribute data-csrf-token of the element #uploader. With an old override every file is refused with the message about an invalid security token.
• Template and snippet overrides of the front end keep working as they are. Under the hood the layouts and snippets no longer call Joomla directly for a translated text, a link or the form token; the object they are rendered by offers those itself. In an override, $this->t('COM_EVENTGALLERY_...') translates a language key, $this->url('index.php?option=com_eventgallery&view=...') builds a link, $this->token() prints the form token field and $this->snippet('event/inc/thumb_link') renders another snippet. New overrides can use these instead of Text::_, Route::_ and HTMLHelper::_('form.token') - that is what the shipped files do now. An existing override which still calls the Joomla classes renders exactly as before, so there is nothing to change. $this->loadSnippet() still works; $this->snippet() is its new name. The folder of the overrides is unchanged: templates/<your template>/html/com_eventgallery/snippets for a snippet, templates/<your template>/html/com_eventgallery/<view> for a layout.

Buying images

• A new payment method PayPal Checkout speaks the PayPal API of today. The shop creates the order through PayPal’s Orders API, sends the buyer to PayPal to approve it and collects the money when they come back, so it learns the result by asking PayPal instead of waiting to be told: there is nothing to register at PayPal, no notification address and no webhook. All it needs is the Client ID and the Secret of an app in the PayPal Developer Dashboard. This is the method to pick for a new shop. The older PayPal method, which uses PayPal’s Website Payments Standard and its IPN messages, is unchanged and keeps working, so nothing has to be migrated. In PayPal, a payment carries the order number followed by a short code as its invoice ID; the code is specific to your site, so two shops paying into the same PayPal account never present PayPal with the same invoice ID twice.
• Several images can be put into the cart at once. In buy mode every thumbnail carries a tick; a bar at the bottom of the page counts the selection and opens one format dialog for all of them. Formats which not every selected image offers are shown greyed out with the images they do not apply to.
• The cart page saves every change right away: quantity, format and comment update the totals without a reload, and "Continue shopping" leads back to the galleries, as does the empty cart page.
• The format dialog shows what is in the cart, keeps its buttons reachable on small screens, and the cart icon on a thumbnail carries the quantity in the cart.
• The checkout data page has a cleaner layout with the payment and shipping methods as selectable cards, while the form controls keep the look of the Joomla template.

Mails

• The mails to your buyers - order confirmation, payment and shipping notification, and the mail which shares an image - are new. They are readable on a phone as well as on a desktop, work in Outlook, Gmail and Apple Mail, follow the dark mode of the mail program and start with your logo or the name of your site instead of plain text. The order confirmation shows the ordered images with their thumbnails - sharp on screens with a high pixel density; your own templates can use them as {$lineitem->thumburl_large} with a width attribute -, the costs, both addresses with company and VAT ID, and what the payment method has to say - the pay now button of PayPal or Stripe is a real button now. The subjects carry the order number. Three options in Options → Checkout make the mails yours: Logo, Accent Colour and Address, which replaces the "Peter Lustig" every shop signed its mails with until it wrote own templates.
• Event Gallery → Email Templates now starts with an overview which tells, for every mail and every language of your site, which mail your buyers get: your own template, your own template for all languages, or the mail which comes with Event Gallery and in which language. Until now a shop without own templates had an empty list and no way to see its mails short of placing an order. Each entry lists your own templates for that mail and language, also the unpublished ones, and where there is none New customisation creates one, filled with the mail which is sent right now.
• Editing an email template got easier. The preview shows the mail as it is typed - press Refresh, you no longer have to save a template, and with it put an untested change live, to see what it does. It shows the mail at the width of a desktop and of a phone as well as the text version, and it tells you what is wrong if the template contains a mistake. The body is edited in Joomla’s code editor with syntax highlighting, if the Editor - CodeMirror plugin is enabled. A list of Placeholders replaces the dump of the example data, and Load Default loads the mail of the purpose and language chosen in the form.
• The mail which tells you that a visitor reported an image is an email template now, like all other mails: Reported Image (to the administrators). It shows the message, a thumbnail of the image, its event and links to the image and to the messages in the back end; a reply goes to the visitor if an address was left. The thumbnail travels inside the mail, so it also shows for an event which is password protected or limited to a user group. It is written in the default language of your site, and you can change it like every other mail.
• Every mail now carries a plain text version next to the HTML version. Mail programs which show text only - or buyers who prefer it - get a readable mail with all links instead of an empty one, and spam filters rate a mail with both parts better. The text version is made from the HTML version automatically, also for your own email templates.
• The new mails are built from one frame and a few building blocks (_layout.tpl, _lineitems.tpl, _summary.tpl, _addresses.tpl and others) which your own email templates can use too. The chapter on email templates lists them. To change the frame or a building block for all mails, put a copy of the file into templates/<your site template>/html/com_eventgallery/mail; it replaces the original and survives updates.

S3 storage

• S3 storage with more providers and several accounts. Event Gallery no longer knows only Amazon S3 and one set of credentials. Under Accounts - S3 Storage you create as many S3 accounts as you need, each with its own service, access key and buckets: Amazon S3 or any service which offers the S3 API, such as Cloudflare R2, Backblaze B2, Wasabi or Hetzner Object Storage. Choose your provider in the form of the account and Event Gallery fills in what it knows about it. An account knows the endpoint and region of the service, whether buckets are addressed by host name or by path, and an optional public address for the thumbnails (a CDN or a custom domain, formerly the option CloudFront domain). Thumbnails can be made public by the policy of the bucket instead of an access control list per file, which is what providers without ACLs and new Amazon S3 buckets require. Two buckets stay the default, one for the private originals and one for the public thumbnails, but an account also works with a single bucket: leave the thumbnail bucket empty, and Event Gallery keeps the originals below originals/ and the thumbnails below resized/, so that a bucket policy can publish the thumbnails alone. Every account has a button Check the connection: Event Gallery signs in, writes a test file and then asks for it without credentials, the way a stranger would. You see whether the account works and, above all, whether your original files are really private; a bucket which is public by mistake is reported. When you create an event with the image source S3 Storage (formerly Amazon S3 Images), you choose the account which holds its images; the sync finds new folders in the buckets of all accounts. See the section called “S3 accounts”.

Upload

• The upload page tells you where you are and what it takes. Its title read "Event: [ upload ]" in every language, it named the event by its folder only, and the one way out besides Close were the files and the edit page of the event. It now carries a translated title, calls the event by its name like the list of events does, and says which file types you can upload and how large a file may be - with the PHP settings the limit comes from, so you know what to ask your host for. The toolbar takes you to the overview and to Event Gallery → Manage Events as well, like the three maintenance pages do. The front end shows the same page without the hint about PHP settings. The manual has a section Upload Files now.
• The upload page shows every file with its own progress, state and way out. The page used to list the names of the waiting files and, once a file was through, its thumbnail - nothing in between, no way to stop a file and no word about what happened to a file which failed. Every file now has a row which says whether it waits, is being sent, is processed by the server, is done or failed and why, with the bytes sent while it uploads; a bar above the list shows the whole run. You can drop files onto the page, add more while the upload runs, cancel a file or the whole run, and send failed files again. Before a file replaces a file the event already has, the page asks - Overwrite or Skip, per file or for all of them at once - and the summary at the end says how many files were uploaded, failed, skipped or not added, and links to the files of the event. The browser warns you before you leave the page while files are still waiting. When your login expires or the connection drops in the middle of a long upload, the page pauses instead of failing every remaining file, says why, and Resume carries on where it stopped - with a fresh security token after you logged in again in another tab. Screen readers hear what was added, why the upload paused and how it ended, and every control is a real button which can be reached with the keyboard. Images picked from Google Photos go through the same queue: each is fetched from Google and uploaded in turn, with its own row, instead of all of them being downloaded into the browser first, and a video Google is still processing is named instead of silently left out.

Maintenance pages

• The lists of the three maintenance pages use the width of your screen. A row is a checkbox, a name and a state, so on a wide administrator screen two thirds of every line were empty while a site with a few hundred events scrolled for pages. The rows now stand in as many columns as your window has room for - three on a wide screen, two on a narrower one, one on a small one - and a row which has an error to report still takes the whole width for it.
• An event tells you how far it has got. On Event Gallery → Sync Database and Event Gallery → Thumbnail Creator, an event said done as soon as the page had looked at its folder - with all of its images still to be read or created. It now fills up green from the left while its images are worked through and counts along underneath ("25 of 72 images"), and it says done when its last image is through. An event whose images could not all be handled turns red, and the images themselves are still named one by one at the end of the run.
• Event Gallery → Sync Database and Event Gallery → Thumbnail Creator call your events by their name. Both pages listed nothing but the folder an event lives in, so an event called Mallorca appeared as 2013-10_Malloarca. A row now reads like a row of the event list: the name of the event, and under it the folder and the date. Where an event is called exactly like its folder, the name is not repeated.
• You can search, filter and order the lists of the three maintenance pages. On a site with a few hundred events, Event Gallery → Sync Database and Event Gallery → Thumbnail Creator showed you a few hundred rows in no particular order. Both pages now have a search field above the list, a filter and an order. They start with the newest event on top; events which are not in the database yet have no date and sit at the end, and the filter New events only takes you straight to them. If you keep images in more than one place, you can also show only the local events or only those of one S3 storage. Select all takes what is on screen, so you can narrow the list first and then tick everything it left over - what you ticked before stays ticked even when the filter hides it. Event Gallery → Clear Cache has a search field and an order too, with the largest entry first, which is usually the one worth emptying.
• Event Gallery → Clear Cache runs on the same new page as the two other maintenance screens. It asks before it throws anything away, clears one entry at a time and says at the end what it emptied and what it could not - until now it only looked at whether the server answered at all, so an expired login was reported to you as a cleared cache. Entries which hold nothing are left out, and if there is nothing to clear the page says so instead of showing an empty list. The sizes it shows are right now; they used to count the folder entries themselves as well as the files, so every number was too large.
• Event Gallery → Thumbnail Creator runs on the same new page as Sync Database. One Start button finds the missing thumbnails and creates them, Find missing thumbnails only does the search alone, and Stop really stops. Nothing is ticked for you here, because creating thumbnails is expensive. The important change is at the end: the page now names every image whose thumbnail could not be created, with the reason. Until now it reported every image as done whatever happened - a file the server could not read, an upload to S3 which failed, a format it does not support - and the only trace was in the Joomla log. Refresh thumbnail hashes now says that it applies to S3 events only; for local events it never did anything.
• Event Gallery → Sync Database has a new page. One Start button runs both phases one after the other instead of two buttons you had to press in turn, and a second button Synchronize events only runs the first phase alone - it brings the events and their file lists up to date without reading the images, which is the expensive part. Every event shows its own state while the run goes - waiting, running, done, failed - and at the end the page says how many events and images it processed and names everything which did not work, with the reason. Stop really stops: the requests which are on their way are ended, and the page says how much was done and how much is still open instead of reporting a failure. Ticking an event works by clicking its name as well as its checkbox; until now a click on the checkbox itself toggled twice and did nothing.

• The button which deletes what you ticked in a backend list was labelled Remove in every language, because its label was a hard-coded English word. It is now Delete, and Löschen on a German backend - Joomla’s own label, which you see everywhere else in Joomla and which Event Gallery → Manage Events and Event Gallery → Accounts - S3 Storage already used. The image list of an event keeps its own Delete images, which says more than either.
• Event Gallery → Sync Database, Event Gallery → Thumbnail Creator and Event Gallery → Clear Cache have a button Manage Events in their toolbar, next to Overview. These three pages hide the main menu while they are open, so the toolbar is the only way out of them, and the list of events is where you usually want to go next.
• The console command eventgallery:create-s3-thumbnails has a new option --folder. It limits the run to single S3 events instead of walking through all of them, for example right after you uploaded a new event. The option can be repeated.
• Removed the two Search plugins for events and images. They integrated with the old Joomla Search component (com_search), which Joomla removed with Joomla 4, so they had nothing left to hook into on the Joomla versions this release supports. The update uninstalls them if they are still present. Searching for events and images keeps working through the two Smart Search plugins, which integrate with com_finder and are unchanged.
• Removed the Installer plugin. It used to add the Download ID to the update requests of the commercial packages on Joomla 3. Joomla does that on its own since Joomla 4, so the plugin had an empty method left and did nothing. The Download ID keeps working exactly as before, you still enter it in the options of the component. The update uninstalls the plugin if it is still present.
• Removed leftovers which only existed so that Joomla 3 could find its way around the component: an empty helpers/route.php, a copy of the EventgalleryHelper class outside of its namespace, and an unused import and an unused method in the form field which selects the working class of a payment, shipping or surcharge plugin. Nothing of this was reachable on Joomla 5 or newer.
• Cleaned the Bootstrap 2 and Bootstrap 3 remains out of the backend markup. Grid classes like span6, the responsive helpers like hidden-phone, the floats pull-left and pull-right, the inputbox form class and the hasTooltip marker have no meaning in the Bootstrap 5 which Joomla ships since Joomla 4, and the elements which open a modal carried their data-toggle attributes twice, once for Bootstrap 4 and once for Bootstrap 5. The rendered pages look exactly the same.
• The installer no longer checks whether it runs on Joomla 5 or newer before it installs the guided tours. Event Gallery 6 requires Joomla 5 anyway, so that check was always true.

• The layout which shows the images of an event in a grid is called Event - Grid List in the backend, but its technical name was simple. That name was confusing in two directions: it did not match the label, and Simple List is at the same time the name of the layout which shows a list of events as text links. The image layout is now called grid everywhere.

  The update rewrites the name in every place it is stored, so your menu items, your modules and the Default Event Layout in the options keep showing the same layout and you do not have to touch anything. Links which still carry the old name keep working as well.

  Two things need your attention if you customised this layout. If you have an override of the layout itself, rename it, otherwise it is no longer used: html/com_eventgallery/event/simple.php becomes grid.php, and for the module html/mod_eventgallery_event/simple.php becomes grid.php. The content of the renamed file can stay as it is - where it still asks for the snippets event/simple or event/simple_thumbnails, it gets their new versions. Overrides of those two snippets keep working under their old names (html/com_eventgallery/snippets/event/simple.php and simple_thumbnails.php); rename them to grid.php and grid_thumbnails.php when you touch them anyway, a file under the new name wins. If you wrote your own CSS for this layout, the two classes it hangs on were renamed as well: eventgallery-simplelist is now eventgallery-gridlist and eventgallery-simplelist-tile is now eventgallery-gridlist-tile. Rename them in your own stylesheet, the old ones are gone.

• The requests the cart makes in the background - adding an image, changing a quantity, emptying the cart -, the two backend helpers which fill the content plugin dialog and count the missing thumbnails, and the requests of Event Gallery → Sync Database, Event Gallery → Thumbnail Creator and Event Gallery → Clear Cache now announce themselves as JSON instead of leaving the content type at the default of a web page. That is what they always were; Joomla now says so in the response. You only notice this if you call one of those addresses from your own code, and the answer itself is unchanged.
• The addresses the cart scripts call in the background have changed from index.php?option=com_eventgallery&view=rest&task=… to …&view=cart&task=…, and the three backend helpers from task=rest.* to task=ajax.*. Event Gallery’s own pages pick the new addresses up on their own. If you call one of the old addresses from your own code, it now answers with a "page not found" and you have to switch; the tasks and their answers are unchanged. The update removes the two old controller files, so they cannot linger on an updated site.
• The Event Gallery options keep the last open tab when you save them.
• The overview page of the backend has a new layout. Instead of twenty cards with a button each it shows a handful of cards, one per group of the Event Gallery menu, with a link and a short description for every area - including the options, the sales statistics, the messages, the tools, the system check and GDPR, which the old page did not link. It uses the plain look of the Joomla backend, in the light and in the dark colour scheme, and it works on a phone, where the cards stack below each other. The getting-started video is a link now instead of an embedded player, so opening the page no longer loads anything from YouTube. The free version shows what Event Gallery Extended adds at the top of the page. If you have a template override for eventgallery/default.php in your administrator template, it keeps showing the old page; remove it to get the new one.
• The screenshots in this manual are now generated automatically from a Joomla 6 test site by the test suite of Event Gallery, so they show the current version of Event Gallery and of Joomla. Every backend page and every frontend layout has a picture now, and the chapters which had none - the cart and checkout pages, promotions, the modules, the content plugin, watermarks, categories, the GDPR export - got theirs. Only pages of external services, such as the AWS console or flickr.com, are still hand-made.
• The Stripe payment plugin no longer ships Stripe’s PHP library. It talks to Stripe through two plain requests of its own, which makes the plugin a few files instead of four hundred and removes a class loading conflict which earlier updates of that library kept reintroducing. The update removes the old library folder from your site. The checkout no longer loads Stripe’s JavaScript into your pages: the Pay now button leads to the payment page Stripe hosts, which is also what Stripe recommends today, and the payment at Stripe is created only when the button is clicked instead of every time the confirmation page, the tracking page or a mail is rendered. The Public Key field of the payment method is gone because nothing needs it any more; the Secret Key is all Stripe needs. Nothing changes in the Stripe dashboard, and existing payment methods keep working.

• The question you got before deleting in Event Gallery → Email Templates, Event Gallery → Watermarks, Event Gallery → Payment Methods, Event Gallery → Shipping Methods, Event Gallery → Surcharges, Event Gallery → Order Statuses, Event Gallery → Image Types, Event Gallery → Accounts - Flickr or Event Gallery → Accounts - Google Photos asked "Remove all selected Events?" - whatever the list in front of you actually held -, and the lists of image type groups, image type sets and messages asked about "groups" or "items". None of these questions was ever translated either, so a German backend asked them in English. Every one of these lists now asks about the thing it holds, in the language of your backend, and two of them say what deleting costs you: Event Gallery → Order Statuses tells you that the statuses Event Gallery needs itself are kept, and Event Gallery → Email Templates that a mail whose template you delete then goes out with the next template for the same purpose, or with the one Event Gallery ships.
• The German question before deleting events now carries the warning the English one always had. On Event Gallery → Manage Events the English backend has always said that deleting events also deletes the image files on your server and that there is no undo, while the German one only asked whether the deletion should really start - so a German site owner was never told that the files go as well. It says so now. Two more German questions were corrected along the way: the one before deleting orders and the one before deleting the images of an event.
• On Event Gallery → Sync Database, Event Gallery → Thumbnail Creator and Event Gallery → Clear Cache, pressing Start cleared only the events you had ticked for that run. Every other event kept the green done and the note from the run before it, next to a run which does not touch it - so the list said something different from the summary underneath. A run now clears every row, keeps the events your storage could not read marked as broken, and marks the events it is about to work on as waiting.
• Event Gallery → Clear Cache reported a cache as cleared even when the request had been refused, for example because the page had been open long enough for its security token to expire. It now says what went wrong. The same page showed cache sizes which were too large, and a cache folder whose name contains a space, an ampersand or a plus sign was not cleared at all although the page said it was.
• Event Gallery → Thumbnail Creator reported every image as done even when its thumbnail was never created, so a run over a folder with unsupported files looked like a complete success. It now says which images it could not do and why.
• Event Gallery → Thumbnail Creator could fail every image of an Amazon S3 event with "Cannot open file for writing log" and create no thumbnail at all. That happened when PHP could not write one of the log files of Event Gallery in administrator/logs - for example because a cron job had run eventgallery:create-s3-thumbnails as a different user than the web server and so owned the file. A log entry which cannot be written no longer stops anything, there or anywhere else in Event Gallery: it goes to the error log of PHP instead, and the work carries on.
• On Event Gallery → Sync Database a click on the checkbox of an event did nothing, because the row and the checkbox both reacted to it and cancelled each other out. Only clicking beside the checkbox worked.
• Event Gallery → Sync Database, Event Gallery → Thumbnail Creator and Event Gallery → Clear Cache now turn a request down when the form token has expired or the user may not manage the component, instead of answering with something which looks like a result. This matters when you leave one of those pages open for a long time and come back to it: on the Thumbnail Creator such a request used to end in a PHP error, and on the Clear Cache page it was reported to you as a cache which had been cleared although nothing had happened. On Sync Database the refusal is now shown with its reason; the other two pages stop quietly, so reload the page to get a fresh token.
• The checkbox Download resized images of the Google Photos upload had no effect: every photo was fetched from Google at the size the option sets, even with the checkbox switched off. Switched off, the original is now fetched again. Videos are unaffected, they were always taken as they are.
• The upload page ran into a JavaScript error while it was looking for your Google accounts when there was none yet. The page told you to connect an account, which is right, but the error stopped the rest of the account handling. The picker now simply offers the link to the account management.
• The upload page of the front end offered Google Photos as a source, although the front end cannot answer its requests: picking that tab ended in an error for every publisher. The front end now offers the files of the device only; Google Photos stays available on the upload page of the back end.
• The upload page listed a file the server had refused among the uploaded files. The server answered every refusal - a file type which is not allowed, a file which is no image, a missing permission - with a sentence instead of an error, and the page took every answer for a success; some of those sentences did not even name the file. A file which is larger than upload_max_filesize of your server, and a file the server could not store, ended in an error page instead, and so did every file once your session had expired while the upload page was open - the whole error page was put into the list. The server now says what happened to each file, and the page shows a refused file as failed, with its name and the reason. When the server itself fails, the cause is written to administrator/logs/com_eventgallery.log.php.
• If Amazon S3 could not be reached or refused the request while an S3 event was synchronised, Event Gallery read the failed answer as an empty folder and removed that event from its database. The files in the bucket were never touched, but the event had to be created and synchronised again. A folder whose listing fails is now reported as failed on the sync page and by the console command, the reason is written to the log, and the database stays as it is.
• On a site with Amazon S3 folders whose PHP error reporting shows notices, the backend never told how many thumbnails are missing: the overview page stayed at "loading" and the warning on the overview page and above the event list did not appear. A notice ("Only variables should be passed by reference") ended up in front of the answer and made it unreadable. The same notice could appear when the hits of an event were reset, when a default order status was set and when the thumbnails of an S3 image were recorded. All of these places are fixed.
• On the overview page of the backend, Image Type Groups led to the image types instead of the image type groups.
• On PHP 8.5 an image type which belongs to no group made Event Gallery log a deprecation notice every time the type was looked up, because the lookup asked for a group with an empty id before checking whether there was one. It checks first now. Nothing changes for the buyer; the notice is gone from the logs.
• The build number which the dashboard title and the system check show next to the version named the wrong commit: the build read it from a Git bookmark which points at the state before the last merge or pull, not at what was actually built. It now names the commit the package was built from, so a bug report which quotes the build number points at the right code.
• The bar at the bottom of a gallery with images for sale said "The images of this event are for sale". Visitors do not know that Event Gallery calls a gallery an event, so it now says "The images of this gallery are for sale". Sites which override the language string keep their own wording.
• On the order review page the Edit and Buy now buttons touched each other. They now have the same spacing as the buttons on the cart page.

• The installer never removed the stale files it meant to remove. It kept a list of leftovers from older versions - the language files in the global language folders, two obsolete SQL update files, the Joomla 3 entry points eventgallery.php and controller.php, and the old CLI scripts in /cli - but it asked whether each of them was a folder before deleting, which a file never is, so the list had no effect. Those files are cleaned up now.

  If you still call one of the old CLI scripts /cli/eventgallery-sync.php, /cli/eventgallery-s3-thumbnails.php or /cli/eventgallery-local-thumbnails.php from a cron job, that script is gone after this update. Use the console commands instead, for example php cli/joomla.php eventgallery:sync.

• Sometimes an image did not end up in the cart although it had just been added. Two things came together here. Changing a quantity in the format selection sends the new cart to the server in the background, and the Buy now button was usable straight away - clicking it fast enough left the page while that request was still on its way, and leaving a page cancels its requests. Both buttons now wait until the cart has been saved, and a failed save says so instead of staying silent.
• The script which delivers the images wrote the session back on every thumbnail, although it only ever reads it. A gallery page loads many thumbnails at once, and because Joomla does not lock the session while reading, the last of those requests could overwrite everything which happened in the meantime - a freshly added article in the cart, for example. It leaves the session alone now.
• Sharing a link on Facebook often showed no preview image on the first attempt and only worked once the same link was shared a second time. The pages named the preview image but never said how large it is, so Facebook had nothing to draw a card with until it had fetched the image itself. The page of an event and the page of a single image now send the width and the height of the sharing image along with its address.
• The address which the page of a single image announced as its own was always built with http://, even on a site which runs on https://. Every service which reads that address followed a redirect on each request, and likes and shares could end up split over the two spellings of the same page. That address now uses the scheme the site actually runs on.
• The thumbnails of the Event - Grid List layout were not centered in their tile, although that is exactly what the layout promises. They sat a few pixels too far to the right, which was easy to miss in a wide gallery but obvious in a narrow module in a sidebar, where the thumbnail touched the right edge of the module and left a visible gap on the left. In a slider they were off vertically as well. A slider is as tall as its tallest slide, and neither the slides nor the thumbnails inside a slide were centered in the room they had, so a thumbnail which was not the tallest one of its row hung from the top with all of the empty space below it. Outside a slider the rows were already centered, which is why this only showed up in a module with the slider turned on. Thumbnails now sit in the middle of their tile, horizontally and vertically.
• Deleting images of an Amazon S3 event in the backend deleted the original files, but their thumbnails stayed in the thumbnail bucket, publicly reachable and taking up storage. Deleting an image now removes its thumbnails as well, and for a video also the copy Event Gallery keeps in the thumbnail bucket for playback. Thumbnails of images you deleted with an earlier version are not cleaned up; you can remove them in the AWS console. Deleting a whole event still leaves the files in both buckets untouched, as before; the chapter on Amazon S3 explains this.
• When you upload an image into an Amazon S3 event, Event Gallery removes the old thumbnails of that image before it creates new ones. It sent those delete requests to the bucket of the original images instead of the bucket of the thumbnails, so they found nothing to delete and old thumbnails stayed in the thumbnail bucket until they were overwritten. The requests now go to the thumbnail bucket. Your original images were never at risk, because no original image is stored under the name of a thumbnail.
• In the Slide layout of the Event module the frame around a thumbnail - its border, its rounded corners and its shadow - was drawn across the full width of the module no matter how wide the thumbnail itself was, and the image sat in the left corner of that empty frame. The frame now hugs the thumbnail and sits in the middle of the module.
• The preview and the test mail of the email template Shared Image showed a broken picture where a real mail shows the shared image. Both now show an example image.
• The upload page keeps your login alive while it is open, the way the edit forms of Joomla do. A large upload easily takes longer than a session lasts, and once the session had ended every further file was refused.
• On a server whose PHP sets no limit for the size of a request (post_max_size = 0) the upload page uploaded nothing at all: every file you selected disappeared without a message, because Event Gallery read "no limit" as a limit of minus one byte. No limit is no limit now. A message about a file which is too large names the limit the way you would say it ("28 MB") instead of the way php.ini writes it, and the file dialog of the upload page only offers the file types Event Gallery takes.
• The upload page answered the id of an event which does not exist - an old bookmark, an event somebody deleted in the meantime - with a PHP error. It is a plain "not found" now, in the back end and in the front end.
• The upload page of an event which cannot take files - a Flickr or a Google Photos event, reached by its address, because the lists offer no upload for those - told you that "only local stored events are supported", which has been wrong since Amazon S3 events take uploads, and its Close button did nothing. The page now names both kinds of event which take files, and you can leave it. A file which is sent to such an event anyway is refused with that reason instead of a general server error.
• With the payment method Przelewy24 the form for the SMS code was written into the page whenever a mail about the order was put together - while the order was submitted, and in the back end when somebody changed the status of such an order or resent the order mail. The form now only appears where it belongs, on the confirmation page of the order.
• On a site with more than one language, the mails about a paid or a shipped order mixed languages: the mail itself came in the language of the buyer, but the name of the payment and shipping method, the Pay now button, the headline of the downloads and the name of the country came in the language of the administrator who changed the status. Everything in an order mail now comes in the language the buyer ordered in.
• The mails about a paid or a shipped order carried the disclaimer in the language of the administrator who changed the status, not in the language the buyer ordered in. On a site with more than one language a German buyer could get an English disclaimer below a German mail, depending on who marked the order as paid. All order mails now take the disclaimer in the language of the order.
• Installing or updating Event Gallery on PHP 8.2 or newer printed three notices "Creation of dynamic property … $app is deprecated", from the install scripts of the content plugins, which set a property they never declared and never used. They do not any more.
• Deleting an order in the back end as a user who may not delete orders ended in a PHP error instead of the message that deleting is not permitted, because the code which writes that message was missing two class imports. The message is shown now.
• The order confirmation mail has a place for the company name and the tax id of the billing address, but both stayed empty in a real mail and only showed up in the preview in the back end. They are now part of the data a mail gets, for the billing and for the shipping address, so the shipped template prints them and your own templates can use {$data->order->billingaddress->companyname} and {$data->order->billingaddress->taxid}.