Model Pages planning

The albums are quite the conundrum - I suppose one way (not necessarily a success) would be to ask all members that posted them to take responsibility to transfer them to the new home (when Ed figures out the best method)

In a perfect world, the remaining photo albums posted by long gone members could then be doled out to volunteers …oh yeah, I’m sure THAT would work …

I’d volunteer to do some if it came to that.

Has an album structure been built yet? Something that users can just select the right category and location and dump the photos into?

The new site is a green field. If the old structure still makes sense then we can create an identical one. One of the things I’m trying to get feedback on is just what the structure should be like.

I never heard any complaints about the old one, but I was a user, not a moderator. The only concern I heard was the vetting time and that some times the pictures didn’t show up (probably user error). None of that related to the structure of the album itself.

I assume no one can add new pictures to the old photo album. Can those who posted pictures there delete the one’s they put there previously? If so, perhaps now is the time to encourage all current members to take a look at what they posted and delete what isn’t necessary, useful (or embarrassing). If they can’t be touched is there anyway to open the old site to allow the photos to be touched?

One of the problems we had on the old site was that some albums couldn’t be deleted. If we were to open it to allow addition or deletion of photos that would be a potential risk.

As to the structure, it was how it was. Can we improve on how it was? If the content needs transferring manually then let’s make sure that we take advantage of that opportunity to improve things. There are a lot of albums in the Miscellaneous category, although they contain model specific photos.

Andrew,

My intention would be to automate it, i.e., write a JavaScript/PHP app that does all of albums and JPGs in a given Section in one fell swoop.

The user would launch the JavaScript on his/her PC to see a dialog with a couple fields, e.g., Section and perhaps a date range for flexibility. When the run button is clicked it launches the PHP on a server, say mine or yours. The PHP would create a directory on the server on the same Section name, e.g., XJ-S, then step through all the albums in the that Section, much like it works on the old site now. But instead of simply displaying the JPGs it would download the all the photos in that album and store them in a subdirectory of the XJ-S directory. Additionally, it would write all the critical info like section name, album name and file names into a MySQL database, again on the server. From there, you could do whatever you wished with SQL queries, e.g., load into a WordPress photo album plugin. My daughter Jan might be able to suggest one, out of many that I expect are out there.

I did something similar to this to archive the JOC-LA monthly Jaguar Tales PDF files. Go to www.lajagclub.com and click on Jaguar Tales. Every month the Tales editor uploads the server with a JavaScript/PHP app that knows how to put it in the right directory and insert it into the database.

I don’t want to say it will be easy, but I do think it’s a way forward. I do enjoy programming, but would not even think about doing something this size with a linear manual labor time component.

I want to wrap up my current ConcoursBuilder project before going further with this project though. This mignt be a week, maybe two. Let me know if you agree, or not.

BTW, I now work free, but not forever J

Ed Sowell

'76 XJ-S coupe, red

http://www.efsowell.us

Again, a JavaScript/PHP app could be written for album deletion. I would be quite simple. Section is given, album name is give, the album subdirectory and all JPGs therein are deleted, and the database updated accordingly.

Ed Sowell

'76 XJ-S coupe, red

http://www.efsowell.us

I say we leave the deletions until we get the pics transferred over, that way the owner/users can make the choices themselves.
As to the large number of miscellaneous entries that should have been model specific, perhaps again the ability to re-locate the pic to the appropriate section could be part of the new user edit function.

I like the original format in some ways, and more importantly, if we change the structure, will the links from the archived posts be preserved?

Good point. Would the original pictures be left in the old site and duplicates moved to the new? I’d think that would eliminate that problem.

Another thought is how much of an issue are we talking about. This sites been up a little over 3 months. Is there any way to tell how many searches of the archived posts have been made during that time?

I think the idea is that the old site will be taken offline eventually, no?

I’ve been over there to refresh my memory on a few things quite a bit in the last 3 months but as a newbie I used the picture library constantly …it’s an encyclopedic resource that has to be preserved!

I don’t know; that’s Gunnar’s call.

If it goes off line would that mean the archived posts are gone or will they be migrated somewhere as well?

Have to think about that. Not sure what links you’re talking about.

Ed Sowell

'76 XJ-S coupe, red

http://www.efsowell.us

The original site files should definitely be left in place for as long as there is any significant hits, if that info is being retained. Otherwise, keep it up for a year or so after the transfer and then kill the site.

And while it possible to just access the files at the original site, it’s not a good idea. Sooner or later someone will overlook the account renewal and they will be deleted or ransomed by the people looking for available domain names. And suddenly the new site doesn’t work…

Ed Sowell

'76 XJ-S coupe, red

http://www.efsowell.us

John, the archived posts (old site forums) are already here.

Ed, In the old forum posts, sometimes a user added a bunch of pics illustrating a procedure or descriptor - these photos, previously uploaded to an album, appeared in the post as clickable thumbnails. Clicking on them opened up the album where they were stored so they could be viewed full size along with any additional descriptions.

These are the links I’m referring to, however checking over archived posts post-migration, looks like these links have been stripped out of the posts already :unamused:

On the large number of pics assigned to the miscellaneous class, the reason for this is that it was the default and sometimes users neglected to use the drop down to select the correct sub-group, I know I must have done this once or twice!

Ed,

You just described the transfer process I have in mind for the photo albums pretty accurately. Rather than have each user run it I would prefer to run it as an admin, being able to throttle it somehow (only transfer a certain number of albums per hour). What we would need to do would be something like:

Go to the old site (jag-lovers.org/snaps):

  1. Select the album “X”
  2. Read the title of the album.
  3. Read the URL of the album.
  4. Read the Section of the album.
  5. Read the album owner’s username.
  6. Read the pictures,
  7. Read the descriptions.
  8. Read the URL of each Picture/description pair.

Go to the new site (jag-lovers.com/photos):

  1. Create a new album with the same name and owner.
  2. Add the photos and comments.
  3. record the username, and the URLs of the album and each picture/description in a log file.

Do the next album.

I can then create a job which runs on the forum server which scans the historical posts and updates any which include a reference to the old album so that they point to the new one. (i.e. subsitute “www.jag-lovers.org/snaps/album-x” with “www.jag-lovers.com/photogalleries/username/album-x”)

It probably makes sense if we transfer the old stuff 1:1 in a way which makes it easy to tell the difference between what was transferred, and what has been generated since the migration, but we need to get clear on this before we start. If we do the transfer to the wordpress side, and later change to a different photo plugin or start moving stuff around, then the forum and the static side will get out of sync.

I think Ed’s suggestion of dropping all the stuff into a MySQL database is the way to go, that way we won’t be tied to any particular program (wordpress etc)

They’re there, but finding them via the GUI search function isn’t all that easy. Here is an example:
[xk] The BIG Question - #7 by Tom_and_Cheri_Carson

For that post I would need to replace: “http://www.jag-lovers.org/snaps/
snap_view.php3?id=988389343” with something like “https://jag-lovers.com/albums/tom_carson/Parkinson XK 120 Hot Rod”

Here is the thing about the utility of transferring the old snaps: It doesn’t matter if someone has actually looked at them since the migration, it also doesn’t matter if they don’t seem to contain useful information, what matters is that they contain information. Anyone who has done a restauration knows how often you are faced with a detail question like “Does the wiring harness go through this hole, or that one?”. Transferring the old snaps (and the rest of the old information) is a must, as it contains answers to questions that someone may be asking in the future.

Keeping the old site online costs money (server, domain registration).

Agree totally. Even though late to the party (5 yrs) I could not have accomplished much of my work without the photo archive.

Exactly. If we do some “enrichment” of the content during the transfer to make it easier to zero in on specific types of information then I’m all for it, but the first task is to get clear on how to store and organise the information on the new repository, the second is to transfer it, the third is to update the historical posts so that clicking on a reference takes the user to the correct album.

I started this topic to stimulate discussion on the first of these two tasks: How do we want to organise and present the information on the new site. Once we get some clarity on that the task of transferring the actual information becomes a technical one (not trivial, but technical in the sense of once we know how the old information maps to the new store it becomes something that a program can do).