A month ago we wrote about our plans on how to support taxes in picu E-commerce. The development of this turned out do be much less straightforward and took a lot more time than we anticipated, which is why we weren’t able to release Alpha-3 as planned. In this post we’d like to give an overview of the current status.

Display prices including/excluding taxes?

Some countries, like Germany, have very strict laws about E-commerce. For example: If you sell to end-consumers directly, all prices must be displayed including taxes, which wouldn’t be that hard to do if you serve only Germany, but what about photographers that work internationally and need to support different tax rates? We quickly realized that to properly support this, we would need one (or a combination of) the following:

• Popup/Modal window when clients first visit a store, to choose their country
• A prominent dropdown menu to choose/switch country, that would need to be visible at all times
• Recognize Geolocation by IP address, to automatically select the correct country, when a client arrives at the page

We want to make this as frictionless as possible for clients, which is why the last one – Geolocation by IP – is our most favorable option but as this will take a moment to develop, we needed a workaround that will work right now.

Our current solution

For now, and to not further delay our progress, we decided to simplify the settings for taxes and removed the option so select how to show prices in the frontend and for now will only keep the setting on how to enter prices – including or excluding taxes.

If you activated taxes and entered prices without taxes, we will add “+ Taxes” in the frontend to notice the customer that taxes will be applied during checkout. And finally in the checkout, when the customer was able to chose their country, the exact tax will be calculated and displayed.

If you are in Germany and must display prices including taxes, you can switch the setting to enter full prices including taxes and the prices will be calculated the other way around to display them correctly as well.

There are still things that can be enhanced in the future, but this should be working in a lot of different scenarios already.

Next Steps / Current Planning

• Finish Tax settings and finally ship Alpha-3 to our beta testers for a last feedback round
• Implement the rest of the feedback we got, and some final testing
• Release picu 3.0 including E-commerce until May

Last month, we got a support request about some problems when deleting picu collections. We were able to identify that the problems occurred only when WPML and their WPML Media Translations extension were active, so we contacted their support and started investigating ourselves.

Together with their development and partnerships team, we were able to quickly identify the issue and created a fix that is in testing stage right now and should be ready for the next release.

Early in March we got notified by a user that there were some problems displaying images in their collections.

When we looked into this, we identified that the problem was an incompatibility when the SiteGround Speed Optimizer plugin was active, or specifically a feature that minifies and combines JavaScript files in the frontend, which got in the way with how we load some of our scripts.

Usually, if there is a problem between picu and a caching plugin the first and best thing you can do is turn off ALL minification/combination of JS, CSS or caching options for our specific custom post type picu_collection, if possible.

In this plugin there is no such option to date, which we reported back to the development team at SiteGround, but luckily we also found and implemented a workaround that fixes this from 2.5.3 onwards!

Taxes are an important – and in many cases legally required – part of most online businesses. As we know this will be an important feature for many of you, we want to make sure that picu properly supports taxes, right from the start. Here’s a quick update on where we are right now.

In the new e-commerce settings in picu, you will be able to activate taxes for your store:

Once activated, you can add all the tax rates that you’ll need – depending on the countries you sell into:

And finally, the calculated taxes will show up in the “checkout” modal for the client:

Ok, this is it for now. We expect to ship this to our pool of beta testers next week with Alpha 3, and plan for a public release soon!

If you have any feedback, wished or thoughts about this, please feel free to get in touch with us – we’d love to hear from you!

With our next picu release 2.5.0 it will be possible to use some formatting in client emails using Markdown:

This is what it looks like when receiving the email:

Of course Markdown can also be used in email templates, which are part of picu Pro:

Read more about what you can do with Markdown in our How-To article.

We shared our last status update back in December, which showed mostly what our e-commerce integration looks like from a client’s perspective.

Today I want to share a little bit more about the backend side of things, what the photographer gets to interact with in the WordPress Admin.

1. Selling images can be activated per collection.

We are starting with two pricing types: Single image pricing and package pricing.

2. We also integrated the first payment provider (Stripe), which you can also turn on/off per collection under “Payment Options”:

There will be more provider integrations in the future.

3. Once an order has been placed it can be viewed in the newly added order overview:

4. And of course, you can look at individual orders as well:

We will release the current state as an early alpha version to our beta testers soon.

Next up: Taxes, invoicing and PayPal integration. Stay tuned! 🙂

We announced our plans for an e-commerce integration for picu back in August, and today I’ll share some of our progress.

On the frontend, the interface photographers’ clients see when ordering images through picu, we prioritize simplicity and ease of use and we continue to do so when selling images.

The total price will be displayed in the lower right and is continuously updated while images are being selected:

We already implemented two of the most requested pricing models: Single image (as seen above) and package pricing.

When selling images, the default approval form with a comment box is replaced with checkout fields like name and address, as well as a table that summarizes the order. All those fields will be fully customizable (they are already, actually).

In the follwoing example we used packaged base pricing calculation with a number of included images and extra cost for additional images:

On the backend, we implemented some basic e-commerce settings:

Next time I’ll share the pricing model options and tell you about Stripe integration. 🙂

With our Collection List Shortcode it was possible to display a list of collections anywhere on your site, which was mostly used to build a “Client Area” page for clients. This worked well and even allowed for some customizations like querying for client email addresses, post status (sent, approved etc.) or specific collections by ID that you want to display.

Yet, in the modern WordPress world where everything is made of blocks, using shortcodes felt more and more antiquated and it was time to rebuild this as a custom block.

So during the last few months or so, we spent some time on and off working on a new block to ultimately replace the old shortcode. The new block will allow the same or better level of customization, but will be much easier to configure in the backend, as you would expect from a WordPress block.

Here’s a sneak peak of how this will look like in the backend:

On the frontend side of things, the lists so far looks similar compared to the shortcode and we might add a few small enhancements until release.

Right now, there are only a handful of small bugs to fix before this will be ready for release, so you can definitely expect this to be available in one of the next updates!

It is already over – at least this time around – but I thought it might be interesting to show, how we handle our Black Friday sale in our store. (We use Easy Digital Downloads to handle Subscriptions and Licensing for picu Pro.)

Turn It On, Turn It Off

We use a regular EDD coupon for Black Friday, which is set to be active for a pre-defined timeframe, and we automatically apply it on checkout.

To activate Black Friday, we created a couple of custom settings:

• We can simply turn the deal on with a checkbox in the general settings
• There’s a field to set the coupon code that will be used
• The last day of the deal can be specified, so that we do not have to turn it off manually (in the middle of the night)

This is the (simplified) code we use to automatically apply a EDD coupon on checkout:

/**
 * Automatically apply EDD coupon code on checkout
 */
function maybe_apply_discount() {
    if ( get_option( 'picu_black_friday' ) == 'on' && time() < strtotime( get_option( 'picu_black_friday_end_date' ) ) + 86400 ) {
        $discount_code = get_option( 'picu_black_friday_coupon' );
        $cart_items = edd_get_cart_contents();

        // Make sure there is a coupon and picu Pro is in the cart
        if ( ! empty( $discount_code ) && is_array( $cart_items ) ) {
            foreach ( $cart_items as $item ) {
                if ( $item['id'] == 1234 ) {
                    $has_picu_pro = true;
                }
            }
        }

        // Apply or remove the coupon
        if ( $has_picu_pro == true ) {
            edd_set_cart_discount( $discount_code );
        } else {
            edd_unset_cart_discount( $discount_code );
        }
    }
}

add_action( 'edd_cart_items_before', 'maybe_apply_discount' );

Aside from checking the aforementioned options, we also make sure that picu Pro is actually in the cart, defined by ID 1234 in the example above.

Let It Be Known

Before switching to a FSE theme, we used the same mechanics directly in our PHP theme templates to display the Black Friday banners on the site.

This time around we switched to synced patterns, which makes it much easier and quicker to update the banners, as we can do it without updating the theme itself.

We used the Block Visibility plugin to show the banners during the time of the deal.

This setup works quite well for us and it only needs very little effort to setup every year.

A couple of weeks ago I shared a post showing the early stages of our star rating & filter implementation.

This is a follow up post, showing the current and final implementation – at least for the upcoming picu Pro release.

I think we made some great improvements:

• As you can see, we removed the need to click to reveal the stars. They are constantly visible, if set.
• Internal testing showed, that users can much easier discern the number of stars, if shown the actual stars instead of a number next to a single star.
• A big change was moving the filter and grid size UI from the bottom status bar to the top. While I really loved the old filter implementation, this change will allow us to add more filters in the future and – at the same time – make some room at the bottom for other, upcoming UI challenges.
• Star and selected/unselected filters can also be combined, which will allow for a much more fine grained selection process.

Stars can also be changed in the lightbox view:

Besides clicking on the star rating you can also use your keyboard by typing a number between 1 and 5 to change the star rating.

Star rating & filter will be a Pro feature and we are very excited for this update!

Not an email you want to get on a Saturday:

Turns out, when we refactored our settings, we changed the “Show picu love” setting to “on” by default. The WordPress.org guidelines however state, that “Plugins may not embed external links or credits on the public site without explicitly asking the user’s permission“.

Fortunately – thanks to how picu settings work – it was a very quick and easy fix:

Until now filtering images in a collection was only possible between “selected” or “unselected”.

I wanted to make this more flexible and landed on star rating/filtering.

Star ratings are pretty common and universally understood, although the usual use case is rating products or movies. Still, the concept remains the same: More stars mean “better”. Also, photo management software like Adobe Lightroom have supported star ratings basically forever.

This will make the selection process much more flexible, especially when dealing with lots of images. For example, it will allow making multiple selection rounds, assigning one star in the first round, two in the next, etc., ending up with a final selection which can then actually be selected – and sent to the photographer.

Below you can see a video of the current implementation of star ratings for individual images and the filter:

Please note, that this is still in early stages, so the implementation will probably change for the final release.

With picu 2.3.0 and picu Pro 1.4.0 collections do no longer close automatically. Before collections would close once the last client approved their selection. With the introduction of client (self) registration, this no longer made sense.

We still wanted to make it easy for the photographer to close the collection once everyone is done.

So we added a new “Close Collection” button to the notification email, that the photographer gets, when a client approved a collection.

This button will only be added once the last client has approved their selection.

And this is what it looks like:

The button will be part of the picu Pro 1.4.8 release.

picu collections are never meant to be public, that is why we remove them from XML sitemaps, have robots meta directives set to noindex, etc..

(Short excursion: For various reasons we cannot set our collection post type to ‘public' => false, because they are public, as in they need to be displayed in the front end – just not for everyone.)

We try to support the most common SEO plugins. And by support I mean, make sure that users do not accidentally add their collections to search engines.

We implemented this for the Yoast SEO plugin a long time ago, but until now our custom post type still showed up in the Yoast settings. The settings for picu collections didn’t do anything, but they were still visible, which made it confusing for our users. (I even created an issue on GitHub years ago.)

We recently found this new filter wpseo_indexable_excluded_post_types, which not only allows us to excludes picu collection from being indexed by Yoast, it finally also did the trick of removing collection from the Yoast settings. 🥳

This is the code we used:

/**
 * Exclude collections from Yoast SEO indexable creation.
 *
 * @since 2.3.6
 *
 * @see https://developer.yoast.com/features/indexables/indexables-filters/#post_types
 *
 * @param array $excluded Array of excluded post types by name.
 * @return array The filtered post types.
 */
function picu_do_not_create_indexables_for_collections( $excluded ) {
	$excluded[] = 'picu_collection';
	return $excluded;
}

add_filter( 'wpseo_indexable_excluded_post_types', 'picu_do_not_create_indexables_for_collections' );

With picu Pro you can add markers and comments to individual images.

We now also display the date, of when the comment was made.

This is what it looks like in the frontend:

Backend:

This is only the very first step to enable a more interactive workflow. The goal is to allow a back and forth of messages, discussing individual images between client and photographer – and finally between several different clients as well.

I worked on improving a particular function on the collection edit screen: Adding a client to an open collection.

This is what the previous modal looked like:

This is the new version:

I updated this dialog with the following features:

• Adding a name field. (Which is already possible for clients themselves in the front end, so this establishes feature parity)
• Making the sending of the email optional. (As some clients prefer to send collection links through other channels, it makes sense to make this optional here as well.)

I also made the checkbox somewhat dynamic, by only allowing it to be checked, if the email field is not empty:

(Could be improved by checking if the input is actually a valid email address.)

Yesterday we sent out a newsletter asking for feedback from our users about e-commerce integration into picu.

Selling images directly through picu, as part of the proofing workflow, has been one of the most requested features and we feel like it is finally time to get to work on it.

But we want to make educated decisions on which features make the most sense for the majority of our users – hence, the survey.

So if you are a picu user and have a specific workflow in mind, please fill out the survey, and let us know! Cheers!

PS: Quick note, because it came up in some of the survey replies already: The existing, easy-to-use proofing workflow will always be the core of picu. E-commerce will extend the workflow for photographers who need/want it. If proofing is everything you need, skip right along.

With our last release we added a registration form, so that clients could identify themselves before making a selection. This enables the photographer to share the same link with multiple clients – or even allow the client to share the link with colleagues, etc.

We also added a setting whether entering an email address was required during registration. Unfortunately the setting and the registration form were somewhat confusing.

Many users thought that this option would turn the registration feature on or off. What made this additionally confusing was the fact, that the registration form did not reflect the setting.

The previous setting:

The previous registration form:

I updated the setting to

• make it clear, that it only controls, whether an email address is required during registration
• I added a note, explaining that a confirmation email is always sent if an email address is entered – whether the field is required or not.

The updated setting:

This might not be final, but I think it is already much clearer than the previous version.

The updated registration form (email not required):

I made it clear, that the email field was optional and updated the intro paragraph to not explicitly mention the email anymore.

Welcome to the picu Dev Log.