Feature Request: REAL Calendar View

Will be considered

Something like this: https://betatest.opajaap.nl/test-pagina/ ??

Yes! Except provide text (photo count) over image or mouseover event to show how many photos on that date.

Ok, still working on it.

Would you like: upload date, modified date or exif date? (currently implementing all three).

Do you need to specify in the shortcode on what month to start, or will current month be sufficient?

Something similar to this. Note the mouseover action.

Exif date for me. I am documenting granddaughter’s life, so Date Taken date will be used. But maybe that can be selectable in settings for other uses? Or maybe reordered/overridden by shortcode. Starting at current month is great, with controls for Next Month, Previous Month, Next Year and Previous Year

• This reply was modified 5 years, 5 months ago by cholzsch.
• This reply was modified 5 years, 5 months ago by cholzsch.

The shortcode will be extended with 3 additional options to the calendar="" attrinute:
realtimestamp, realmodified and realexifdtm, so you can have e.g.:
[wppa type="calendar" calendar="realexifdtm"], optional with album="" attribute.
Album arg may only be numeric or numeric enumeration (no virtual or name). Default all albums.
Example:
[wppa type="calendar" calendar="realexifdtm" album="1.4..7.18"]
meaning: look only in albums 1,4,5,6,7 and 18.

The left arrow will go from january to december previous your etc.

– do you want a previous/next year button?
– do you need a month selection direct access row?

I think previous month “<“, previous year “<<“, next month “>”, and next year “>>” buttons are needed when photos exist earlier or later than current month. That way, you can go back, and then forward in time, month by month or year by year. A month selection direct access row would be great, like in the image I linked to. That would allow better/faster navigation between months. (Maybe even a text box with image count for that month under the selector) Also, note the “Today” button in the image. This would allow for a quick link back to current month.

Ok, will be done that way. I will come back to you in a few days when a stable working test version is available.
In the mean time you can have a look at https://betatest.opajaap.nl/test-pagina/ to see the progressions, but tha page may spuriously be broken during development.

Please do as explained here:
https://wppa.nl/docs-by-subject/development-version/
and tell me if you encounter any issues.

In case of any issues, pls supply a link to the page.

Note the changelog (fragment):

* New shorcode attribute values for type="calendar". The new values are ‘realtimestamp’, ‘realmodified’ and ‘realexifdtm’ for the attribute calendar="",
so you can now have a ‘real look’ calendar using shortcode:
[wppa type="calendar" calendar="realexifdtm"], optionally add the album="" attribute.
Note: Only numeric albums or numeric album enumerations are supported. E.g. album="7" or album="1.5..8.19", meaning albums 1,5,6,7,8 and 19.
* New shortcode argument for all calendar types: parent="x" where x is a single album id. When using parent="" it overrules the album="" argument.

Great work! Looks great. One thing that gets lost with the modal window is the ability to leave comments. Any way to display the images inline for the date clicked so the comment system can be used?

I will add linktype ‘slideshow’, and the slideshow will be displayed directly below the calendar, so you do not need to go back a page, just scroll up to select an other day.

This will be released very soon.

Fixed 7.2.10. Make sure you have updated to 7.2.10.013. If you have 7.2.10.012, you must have an album=”..” or parent=”..” shortcode attribute.

You can select ‘slideshow’ in Table VI-C12

Looking great!

One thing I noticed. On a phone, the comment box is cluttered. Can the template for the comment box be changed for a small screen?

Since it’s a 2 column table, it formats the text badly.

Also, possibility to select between username and nickname while displaying comments.

And, username/nickname isn’t needed next to comment box.

See my screenshot and my suggested changes here

I will address the layout issue on mobile devices, in the next minor release.

It is good practise for plugins to use the display_name when a username should be printed. This is for security resons as well as for the compatibility between wp and plugins, so they all use the same name.

The name used (display_name) is the Display name publicly as as you can see on the user profile page. If you want the login name to be used, you will have to change it there.