Forged changes from the lists of the backend (EGSA-2026-06, CVE-2026-102776, severity 5.1). Eight buttons of the backend lists did not check Joomla’s form token: the default of the payment and shipping methods, of the image type sets, order statuses and watermarks; In shop of an event; the main image of an event and whether an image is shown only as the main image; and the sorting of an event’s images. A prepared page on another website could have triggered them while you were logged in to the backend and changed those settings and flags. Nothing could be deleted or read this way, and orders were not affected. All eight need the token now, and the star and the table icon of the image list submit the list like the publish icon next to them instead of following a link. If you have a template override of tmpl/files/default.php of the backend, take over these two buttons from the new file; the old links stop with the token warning.

The Google Photos picker could be made to send its access token elsewhere (EGSA-2026-07, CVE-2026-102777, severity 5.1). The upload page fetches the thumbnails of the Google Photos picker through your server, with the access token of the Google Photos account. The address to fetch came from the request and was not checked, and the request needed no form token: a prepared page on another website could make your server send the token of your Google Photos account to any address, or fetch addresses inside your network, while you were logged in to the backend; a backend user with the permission to manage Event Gallery could do the same directly. Only sites with a Google Photos account are affected, from 5.4.0 on. The server now fetches only addresses of Google’s image hosts, and the picker requests need the form token. Nothing changes for you when you use the picker.

The page a shared image link opens could run a script or lead to another website (EGSA-2026-08, severity 2.3, Low). With the option Share article links on, this page links the article the image was shared from. It took the address of the article from the shared link and printed it as it came, and with the link type Image Page with Redirect it followed the address at once. A prepared link could therefore run a script in the page, in the session of the visitor who opened it, or send the visitor to another website. Only sites with Share article links on are affected, from 3.11.6 on; the option is off unless you switched it on. The page now follows only an address of your own site and escapes it; shared links keep working. Until you update, switch Share article links off in the options of Event Gallery, tab Social.

Authorising a Google Photos account on Google now carries a random state which the callback checks against your session, so a callback which did not start from your account form is not followed.

If you have a template override of the last page of the checkout (checkout/review.php of com_eventgallery), add this field next to token(); ?>: input type="hidden" name="reviewed_total" value="esc(number_format((float)$cart->getTotal()->getAmount(), 2, '.', '')) ?>"/>. It tells the shop which total the customer saw.

The Stripe method no longer offers SEPA Direct Debit, Sofort and Giropay. A SEPA debit is paid days later, which Event Gallery could not follow, and Stripe has retired the other two. Your customers pay with the other methods you switched on, or by card.

Event Gallery comes with English and German texts only. If your site shows Event Gallery in another language with language files of your own or of a translation team, translate the texts which are new or changed in this version as well, for example with Joomla’s language overrides; until then Joomla shows these texts in English.

If you switched the mail off in the Global Configuration (Send Mail: No), your shop now takes orders and payments anyway; the mails it could not send are listed in administrator/logs/com_eventgallery_order.log.php.

Event Gallery no longer uses what Joomla 7 removes and keeps running on Joomla 5.0 and later (#1763). The Smart Search plugins work again on Joomla 5.0 to 5.3, and the JSitemap integration no longer needs Joomla’s backward compatibility plugin.

Searching the order list while a status filter is set finds the matching orders again; before, it found none.

The search of the order list also finds the name and the company of the buyer.

The order list is more compact and works on a phone: one row shows the customer, the three statuses with a colored dot, the images and the total, and the columns can be sorted like every Joomla list. The pencil next to the statuses opens a row below an order to change them without opening it.

The order page starts with an overview and shows the images as a table with the price the buyer paid, the status next to them with a note that Paid and Shipped send an email, and the customer and the addresses. The list for the photo lab and the payment data are collapsed under Technical details, and the list can be copied with one click.

The list of order statuses shows the order, payment and shipping statuses in a group each, with the color of every status, and the arrows move a status within its group.

An order mail which cannot be sent no longer stops the checkout or the payment. The order goes on, and you are told which mail failed and why. Sharing or reporting an image shows a message instead of an error page, too.

An order is only placed at the total the customer saw on the last page of the checkout. If a promotion ended or a price changed meanwhile, the page shows the new total and the customer decides.

A free order is always set to paid and always gets a confirmation with its downloads.

Stripe charges currencies without decimals (yen, won, …​) and with three decimals correctly; it charged a hundred times or a tenth of the price.

A PayPal payment notification which your server could not verify with PayPal is sent again by PayPal later, so the paid order no longer stays unpaid.

Deleting a payment or shipping method no longer breaks the orders and carts which used it.

A failed save in the backend no longer carries its input into the next order or file you open in the list.

The link of the hint The Download ID is missing could open an update site which Joomla cannot edit, and Joomla stopped with the error getDownloadKey(): Argument #1 ($extension) must be of type stdClass, null given. The hint now links only the update site of the installed package, or tells you how to rebuild the update sites when there is none. An update from Event Gallery Core to Extended no longer leaves the update site of the Core package behind.

Path traversal in Clear Cache (EGSA-2026-01, severity 6.5). menu: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, severity 6.1). The btn:[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, severity 5.4). 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, severity 4.3). 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, severity 4.3). 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.

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 menu: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..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 menu: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 menu: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//html/com_eventgallery/snippets for a snippet, templates//html/com_eventgallery/ for a layout.

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.

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 menu: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.

menu: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//html/com_eventgallery/mail; it replaces the original and survives updates.

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 [_s3_accounts].

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 btn:[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 menu: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 - btn:[Overwrite] or btn:[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 btn:[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.

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 menu:Event Gallery[Sync Database] and menu: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.

menu:Event Gallery[Sync Database] and menu: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, menu:Event Gallery[Sync Database] and menu: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 btn:[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. btn:[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. menu:Event Gallery[Clear Cache] has a search field and an order too, with the largest entry first, which is usually the one worth emptying.

menu: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.

menu:Event Gallery[Thumbnail Creator] runs on the same new page as Sync Database. One btn:[Start] button finds the missing thumbnails and creates them, btn:[Find missing thumbnails only] does the search alone, and btn:[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. btn:[Refresh thumbnail hashes] now says that it applies to S3 events only; for local events it never did anything.

menu:Event Gallery[Sync Database] has a new page. One btn:[Start] button runs both phases one after the other instead of two buttons you had to press in turn, and a second button btn:[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. btn:[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 btn:[Remove] in every language, because its label was a hard-coded English word. It is now btn:[Delete], and btn:[Löschen] on a German backend - Joomla’s own label, which you see everywhere else in Joomla and which menu:Event Gallery[Manage Events] and menu:Event Gallery[Accounts - S3 Storage] already used. The image list of an event keeps its own btn:[Delete images], which says more than either.

menu:Event Gallery[Sync Database], menu:Event Gallery[Thumbnail Creator] and menu:Event Gallery[Clear Cache] have a button btn:[Manage Events] in their toolbar, next to btn:[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 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 menu:Event Gallery[Sync Database], menu:Event Gallery[Thumbnail Creator] and menu: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 menu:Event Gallery[Email Templates], menu:Event Gallery[Watermarks], menu:Event Gallery[Payment Methods], menu:Event Gallery[Shipping Methods], menu:Event Gallery[Surcharges], menu:Event Gallery[Order Statuses], menu:Event Gallery[Image Types], menu:Event Gallery[Accounts - Flickr] or menu: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: menu:Event Gallery[Order Statuses] tells you that the statuses Event Gallery needs itself are kept, and menu: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 menu: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 menu:Event Gallery[Sync Database], menu:Event Gallery[Thumbnail Creator] and menu:Event Gallery[Clear Cache], pressing btn:[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.

menu: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.

menu: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.

menu: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 menu: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.

menu:Event Gallery[Sync Database], menu:Event Gallery[Thumbnail Creator] and menu: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.

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 btn:[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}.

I removed the option to select Google Photos albums using the API. I described it back then here: https://www.svenbluege.de/blog/updates/217-oops-they-did-it-again-changes-to-the-google-photos-api-integration

The new promotion engine needs a small manual change to your order mail if you want to use it. Email templates live in the database and are never overwritten by an update, so your existing New Order template does not know about discounts yet. Without the change the mail still shows the correct total, but the discount row is missing, so the listed items and the total do not add up.

{if isset($data->order->promotions)}
{foreach $data->order->promotions as $promotion}

    
        {$promotion->name}
    
    
        {$promotion->price}
    

{/foreach}
{/if}

The Ajax List layout distributes its thumbnails to pages on its own now, so the options Number of thumbs per page and Number of thumbs on first page are gone - globally and on every menu item which used that layout. Your stored values are simply ignored. What replaces them is a single option Maximum height of the thumbnail area, which defaults to 280px, roughly three rows of thumbnails at the default thumbnail size. Set it once if you want a taller or flatter thumbnail area; there is nothing else to migrate.

#1813 Links which carry an event password (&password=…​) do not open the gallery directly anymore. They land on the password page with the password prefilled, and the visitor has to submit the form once. If you handed such links to your customers they keep working, but they take one more click. See the Minor Changes section below for why.

The password page of an Event now renders a captcha. If you have a template override of html/com_eventgallery/password/default.php and a captcha configured in Joomla, add the captcha to your override, otherwise nobody can pass that form anymore. Your override should also render the prefilled password, otherwise those links lose their value: add value="" to the password input. The shipped template does it like this:

form != false): ?>
    form->getFieldset('password') as $field): ?>
        

            hidden): ?>
                label; ?>
            
            

                input; ?>
            
        
    

Removed support for Google Photos via API. Google shut this down in 2025. You can still use the Google Photos Picker to copy images from Google Photos or use Shared Links to Google Photos albums.

New promotion engine. You can now create discounts which either apply automatically or are unlocked by a promotion code. A promotion reduces the price by a percentage or by a fixed amount, either on the whole cart or only on selected image types, and it can also cover the shipping costs. Condition rules decide when a promotion is active, from a simple cart value threshold up to composite rules like "the cart contains 5 images of image type A and 1 image of image type B". Promotions can be limited to a period of time and combined or kept exclusive via a priority.

#1806 New sharing option Send Image by eMail. The existing eMail sharing only puts a link into the mail. The new option sends the image itself, embedded into the mail, so the recipient sees the picture right away and does not have to follow a link. It uses the same image size the download uses: if menu:Event Gallery[Options > Social > Use Original Files] allows the visitor to get the original image, the original goes out, otherwise the largest thumbnail does.

#842 The Ajax List distributes its thumbnails on its own. The layout no longer assigns a fixed number of thumbnails to each page. It measures how many fit into a row at the current window width and fills up as many rows as the new option menu:Event Gallery[Options > Event - Ajax List > Maximum height of the thumbnail area] allows. Every page is filled completely, only the last one holds the remainder.

#1809 New menu item type Event Access. It shows a landing page with a single password field. The visitor enters the password of a password-protected Event and lands directly in that gallery. Photographers can hand out one link plus a password instead of a personal link per customer.

#1722 Sorting Events in the Joomla backend takes the ordering asc/desc for moving the Events into the right direction into account. Moving items up/down will now also use your current filter so you can sort items as expected even if there are filtered out Events in between.

#1704 Improve the layout of the password page for events to make its appeal more modern.

#1763 Adding Joomla 7 support by removing deprecated code and adjusting to modern coding standards.

Extended the FAQ with the steps to switch from on-demand rendering to pre-rendered images.

#1807 Switching between on-demand and pre-rendered images does not require deleting htaccess/webconfig files anymore.

#1808 The backend is full of tabs for different config options. The last open tab will re-open after hitting the save-button.

#1810, #1813 The password page of an Event uses the same brute force protection and the same captcha. Until now a wrong password only added a five second delay after ten tries, kept in the session, which a bot could reset by dropping its cookies - and which tied up a PHP process for every attempt. Now the attempts are counted per session and per IP address, and once the budget is used up even the right password is refused for an hour. Both password pages share one budget.

#1812 The Track my Order page got the same brute force protection. Order numbers are handed out one after the other, so the email address was the only thing somebody had to guess to see the address, the phone number and the download links of an order. Failed lookups are now counted per session and per IP address, ten per hour. The two forms use separate budgets, so guessing order numbers does not lock anybody out of a protected Event.

#1814 Email templates are rendered under a security policy now. A template may use placeholders, {if}, {foreach} and the usual modifiers like upper, truncate or date_format exactly as before, but it can no longer call a static method of a PHP class, read a file of the server with {include file="…​"}, or look at $_SERVER, $_ENV and PHP constants. Editing an email template only asks for the Edit permission of Event Gallery, which is a lot less than a Super User, and without the policy such a template was able to run code on the server. Every shipped template is unaffected. Should a template of yours use one of the blocked constructs it now reports an error instead of rendering.

#1815 Payments are better verified before an order counts as paid. Stripe now checks that the checkout session really was paid and that it was paid in the amount and the currency of the order, and PayPal checks that the money went to the configured receiver account and matches the amount and currency of the order. A payment which does not match leaves the order waiting for payment and writes the reason into the plugin log, so look there if an order stays unpaid unexpectedly.

#1811 The token in the download links of an order now comes from the cryptographic random source instead of uniqid(). uniqid() is mostly the current time, which made the tokens of orders placed around the same moment similar enough to be worth guessing. Links which are already out in your customers' mailboxes keep working - only orders placed from this version on get the new token.

#1738 Videos are not displayed in the lightbox if they are inserted with the content plugin in thumbnail mode.

#1802 Fixes an exception while adding new tags to Events using the batch tool.

Path traversal in Clear Cache (EGSA-2026-01, severity 6.5). menu: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, severity 6.1). The btn:[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. The link now only leads to a page of your own site, and there is none when the address names anything else.

Forged uploads (EGSA-2026-03, severity 5.4). 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.

Forged clean-up in the back end (EGSA-2026-05, severity 4.3). 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. Before, a prepared link on another website could have triggered them while you were logged in to the backend.

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 address in the attribute data-upload-url of the element #uploader now carries the security token. With an old override every file is refused with the message about an invalid security token.

If you have a template override of upload/default.php of the front end, it gets the checked target of the btn:[Back] link from the view; take over the escaping of the link from the new file.

#1158 Allow to limit the maximum size of Flickr images. Right now, it is possible to download the original Flickr image with the download button. The lightbox uses the h-(2048px)-image. Now you can limit the size to the k-(1600px)- or b-(1024px)-image by modifying the config.php-file and create an overload. Please check the manual for details.

#1161 allow different ITPC-fields for title and description. This change is available via config.php file only.

#1163 EXIF data: the focal length is now shown with its 35mm equivalent if available. Example for a 1.5x crop camera: 30mm (45mm).

#1154 Fixes issues with the ISO value in EXIF data written Pentax camera

#1155 If a password was entered incorrectly, the message should show up as an error message. Before it was the default success message.

#1156 PHP 8.1 // Remove deprecation warning on list of files in the backend

PHP 8.1 // removed some deprecation warnings

#1157 allow changing the folder name if the change includes only changes in upper/lower case spelling

#1162 Unable to save event descriptions if using the Arc-editor and multiple languages. If not all descriptions are filled, nothing was saved.

Update Smarty template engine for rendering emails to 4.2.0

#1107 Fixes an exception while opening the Google Photos Accounts page in the back office using Event Gallery Core.