Chapter 10. Releases

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

If you have still such old events/albums/folders, they’ll get unpublished with this update. They do not work anymore anyhow. You can still use Google Photos via the shared Album links or upload images from your Google Photos collection using the Google Photos Picker.

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.

Go to Event Gallery → Email Templates and edit the body of the new_order template. Add this block to the summary table right before the surcharge row:

{if isset($data->order->promotions)}
{foreach $data->order->promotions as $promotion}
<tr class="promotion">
    <td>
        {$promotion->name}
    </td>
    <td>
        {$promotion->price}
    </td>
</tr>
{/foreach}
{/if}

There can be more than one discount because promotions may stack, which is why this is a loop rather than a single row. Besides name and price every entry also offers description and code.

If you never customised your order mail, use the Load Default button in the toolbar of the template instead. It replaces subject and body with the shipped default, which already contains the promotion block. Be aware that this discards any change you made to that template.

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.

If you have a template override of html/com_eventgallery/event/ajaxpaging.php or of the snippet behind it, note that the markup changed: the template renders all thumbnails into a single .page element and the JavaScript splits them up. An override which builds the pages itself keeps rendering, but its pages get replaced on the first distribution.

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="<?php echo $this→escape($this→password); ?>" to the password input. The shipped template does it like this:

<?php IF ($this->form != false): ?>
    <?php foreach ($this->form->getFieldset('password') as $field): ?>
        <div class="control-group form-group">
            <?php if (!$field->hidden): ?>
                <?php echo $field->label; ?>
            <?php endif; ?>
            <div class="controls">
                <?php echo $field->input; ?>
            </div>
        </div>
    <?php endforeach; ?>
<?php ENDIF; ?>

Without a captcha configured in Joomla the block renders nothing, so an override which does not have it keeps working as before.

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.

A promotion can carry any number of codes, each with its own redemption limits. That is what makes personalized codes possible: set up the discount once, then paste one code per recipient into the bulk field and give every code a single redemption. The limits of the promotion itself still apply on top as the budget of the whole campaign.

#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 Event Gallery → Options → Social → Use Original Files allows the visitor to get the original image, the original goes out, otherwise the largest thumbnail does.

Like every other sharing option you can switch it on globally in Event Gallery → Options → Social and turn it off per Event. The visitor gets a small form asking for the recipient address, optionally a name, a reply address and a message. It uses the captcha you configured in Joomla, so leave the captcha empty and there is none. Since images can be large, Event Gallery → Options → Social → Maximum Image Size for eMails defines an upper limit. Larger originals are sent as the largest thumbnail instead, and if even that is too big the visitor is asked to use the download.

The mail itself is a new email template named Shared Image, so you can change subject and text in Event Gallery → Email Templates like any other mail. Every sent image shows up in the download log with the type eMail (large image) or eMail (original image).

#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 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.

That means a narrow window gets more pages instead of more rows, which keeps the thumbnail area from pushing the main image off the screen on a phone. Resizing the browser window redistributes the thumbnails and rebuilds the paging bar right away, and the image the visitor is looking at stays selected and is followed to its new page.

The thumbnails are laid out as a proper grid now: the columns line up across all rows, the remaining space is spread evenly between them, and the last row starts on the left instead of being spread across the full width.

The intro content on the first page is kept. It counts towards the maximum height, so the first page automatically holds fewer thumbnails - which is what the old Number of thumbs on first page option used to do by hand.

Thumbnails of the Ajax List are cropped to the square the Height of the thumbnails option asks for instead of being squeezed into it. The delivered thumbnail keeps the proportions of the original, so a wide image used to end up visibly distorted - the more so the larger the configured thumbnail size was.

The main image of the Ajax List got a stage of its own. Its height now follows the width of the gallery and the viewport instead of the aspect ratio of the image inside it. The image is fitted into that stage without being cropped or distorted, and the space a portrait image leaves next to it is filled with a blurred copy of the same image instead of an empty box.

#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.

The page never opens an Event the visitor could not see anyway, so unpublished Events and Events restricted to a user group stay out of reach. Should one password belong to several Events, all of them are unlocked and the visitor picks one from a short list.

The menu item has an Instructions option: a multilingual text which replaces the generic sentence above the password field, so you can tell your customers where their password came from or whom to ask for it. It accepts HTML, so a link to your contact page works too.

Since this page lets anybody try passwords against every Event of the site, it uses the captcha you configured in Joomla and allows ten wrong passwords per hour. The limit counts per session and per IP address, so dropping the cookies does not reset it. Only a hash of the IP is stored, never the address itself.

#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.

Links which carry the password, like index.php?option=com_eventgallery&view=event&folder=wedding&password=secret, keep working, but they no longer open the gallery straight away. They now land on the password page with the password already filled in, and the visitor submits the form. That one request is the only one which unlocks anything, and it is the one which passes the captcha and the attempt limit.

Letting a GET request unlock a gallery meant that everything which follows a link - a crawler, the link preview of a chat app, a virus scanner in a mail client - unlocked it too, and that an attacker could try passwords without ever meeting the captcha.

If your site sits behind a proxy or a CDN, switch System → Global Configuration → Server → Behind Load Balancer on. Joomla then reads the real visitor address instead of the address of the proxy, which every visitor would otherwise share.

#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.

The tracking links in your order mails are not affected: they carry the right order number and email address, and only failed lookups count.

#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.

The PayPal payment now also carries the order number inside the message PayPal signs, instead of only in the notification address. Payments which were already started before the update still work; they take the old route and say so in the log.

If you use the deprecated PayPal Adaptive Payments plugin, please read its log after the first payment. PayPal shut that API down, so its notifications could not be tried against a real payment - the plugin now refuses anything it cannot check rather than assuming it was paid. Consider switching to the ordinary PayPal plugin.