I was right, uploading took a whack of time. I also don’t much like one aspect of the upload window — if something “fails”, it gives you an error while the screen is still uploading so you can see it, but once the rest of the uploads are done, it just rolls over to a new screen showing the successful uploads. No continued error message to say “64 uploaded, 2 didn’t”. So I wasn’t monitoring as I went, and later in the subsequent phases, I’ve discovered “missing” photos and videos i.e. ones that for some reason didn’t upload successfully the first time. Not a huge problem to fix, just annoying. If the result page showed the “failed” ones, I would have fixed immediately upon upload.

I also underestimated the final size. I thought about 10K in photos, which is about right for the family photos. But with everything else on the site, there are actually 14,147 photos, 500 albums, 24 plugins and 25.1 GB of data. Wow. But that part is “done” (small caveat — there are a few months where there are some special photo collections my wife took, so I’ll need her to figure out which ones of those should be included).

Phase II: Preparing the folders and pictures for viewing

While uploading took time, it was generally mindless, something I could spend a few minutes sorting and adding in the ones to upload, and then clicking the button to start. It could take 60 seconds, or 10 minutes, depending on how many pics or how long of videos, but it was background computer stuff while I do other things.

But once the upload was complete, I also had to start playing with the files and albums online to make them presentable. Oddly enough, one of the first things I had to do is tell it to generate all the “little” thumbnail and square size photos in the background. It does it fast enough, the server I mean, while I wait. Another background task. But I need it done because the second step is to play with the display order, and while doing that, I need to be able to move files around by looking at their little thumbnails. But once uploaded, it’s ON the website, not within a file browser, so there’s no “viewing processor” running to let me see it easily. Instead, the website creates the little thumbnails as extra files and then displays them for manipulation.

In an easier world, the photos I was uploading would all have the exact same filenaming taxonomy, and thus once uploaded, I could sort by the creation date (for example) and everything would be in order.

Except some of the pics come from my DSLR. Others come from Andrea’s iPhone. Others come from a small pocket camera. And still others come from two different apps in my Android phone. Which means they all have their own filenaming convention, and they don’t “sort” easily. And if I edited them at all on the computer, with a crop for example, often the software changes the metainfo so that the file creation date is the date I did the editing, not the original “taken” date. Don’t even get me started on images sent to me by other people where they’ve named them “Dave and Janet at the lake” and then “At the lake with Dave and Janet”. The anal-retentive side of me wanted to impose a filenaming convention, sort them all, get them looking identical, and then upload.

But that is way overkill when it takes me 60 seconds of viewing on my desktop to decide on which photo I’m looking for in a batch. This isn’t a “shared” server where we all have to use the same convention. Ultimately I don’t care what the filename is, other than for quick reference. But, since I can’t rely on the filename or the creation date, I do a manual sort. Most of the time, I do a default filename sort plus the original upload order, and then I just move a few things around. Like putting all the photos of Uncle Dave together, even if I took a couple of other people in between.

However, merely putting them in a good order is not necessarily the biggest job. In most cases, since I already had a working gallery elsewhere, with the same photos already uploaded there (alas, I couldn’t transfer directly), most of the time I’m just matching the new gallery’s order to the old gallery’s order. So, again, most of the time, the order isn’t that time consuming. But for some reason, one of the ones I did today was brutal (about 75 photos in the middle of the batch didn’t get uploaded, and when I did upload them, it gave me a huge batch at the end of the collection that had to be moved — one by one — up to the right space).

At this point, I had a gallery with pictures and videos in them, sounds good, right? Except they had no captions. I mentioned in an earlier post that I was annoyed that I had to put the same info twice in the meta data — once for title so it would appear on the album page, and once for description so it would appear on the single photo pages. I reached out to the Piwigo community, and heard nothing back over the course of a week or two. Okay, I guessed I would have to paste it twice. Then it occurred to me. I had chosen a theme where I *should* be able to alter this in the template, but in reading the template files, I couldn’t find the fields to change. I was looking for something called TITLE or NAME and DESCRIPTION, since that is what the admin pages call them. So I posted on the discussion page for my particular theme, hoping successfully that the creator of the theme would respond.

Which he did. Except his first response was “Good idea, make it a plugin and upload it to the repository”. Except if I *could* do that level of techno programming, I would have already done it. I couldn’t even FIND the fields to work with. So I went looking again, and found two rows of code that looked promising and I posted an update to my question.

So I found picture.tpl and the refs to description include:

data-description=”{$thumbnail.DESCRIPTION}”

in two places. I could change that to $thumbnail.NAME. That would be telling it that the description never gets displayed, I think, just that the field will be the name/title field. It also exists in index.TPL.

Although perhaps I’d be better off trying it as “data-description=”{$thumbnail.NAME}” & “{$thumbnail.DESCRIPTION}” ??

My thought was either to change the template to always show just the TITLE field in both album and picture pages, OR to do a little replacement code to tell it that when it went to display the description, to just first copy the text from the TITLE into it. So either show the title or copy the title into the description and then show the description. Either way, the title would show. Or so I thought. Turns out I was TOTALLY off-base.

The text below the main image is set in [Github] piwigo-bootstrap-darkroom file

template/picture.tpl@L38

No idea why the variable is called $COMMENT_IMG, but it’s the description. If you replace the two $COMMENT_IMGs with $current.TITLE it should do what you want for now.

The data-description stuff is for the PhotoSwipe slideshow.

Of course. The title / description is called COMMENT. Which are not to be confused with the actual comment fields. While the TITLE field means something else. Why didn’t I figure that out on my own? 🙂

Who cares in the end? Not me, cuz I made the tweaks and damned if it didn’t work EXACTLY the way I wanted it to do. Fan-freaking- tastic! No more entering the captions twice. Whew!

Now I still had to set captions for about 10,000 photos, and while some of those were done in batches (i.e. multiple photos with the exact same caption like “Small deer at Parc Omega”), others were variations on a theme (“Day 06 – Trip to Cozumel – Water park” or “Day 06 – Trip to Cozumel – Lighthouse”). Others were individual. A fair amount of work.

The last two things I had to do before each album was ready was to test all the photos and videos to make sure they display or play properly (once in a while, a video wouldn’t play, or I had audio but no video, or the picture was upside down), and then, when all was ready, choose an image from the batch to serve as the image for the album cover.

Generate thumbnails, sort the photos, fix the captions, test the viewing, and choose a cover image. It went a lot faster than I initially thought, but it could not be done quickly or in the background. I had some decent processes in place for a good workflow, but it still required me to do a lot of the grunt work manually.

I finally finished after about two months of work, doing a few albums at a time.