Community @ The Turning Gate

Thanks, Ben -- as suggested here's what I did and the results:

• cleared ttg.log file

• Lr-edited "3-Europe and Africa"

• made trivial change to album set's description

• committed the change ... no error experienced

• so next I tried changing slug from "4a-Europe-and-Africa" to "3-Europe-and-Africa" ... received this warning:

• clicked OK and went to look at website's page ... directory name wasn't changed; that album set tree renders OK

• the ttg.log for all of the above is at http://samcos.com/downloads/ttg20150213_1.log

so -- still can't change the slug BUT at least the album set tree's rendering doesn't get broken.
back to you, Ben!

Changing it to another, temp template and then back worked -- Thanks, Rod.

Success!

1) I used your tool, Ben, and the server's /galleries/ file structure matched the Lr structure dump. So I continued with my promotion/move of the yearly album sets up a level in the album set/album tree. As happened earlier, I'd periodically get a publisher server error resulting in Lr being out of sync with a directory that was moved (but Lr's structure wasn't updated). But I could always FTP the directory back down a level and perform a couple of Lr "edit album set" to get it sync'd up again. There was one directory that I just couldn't move up, so I created a new album set at the root destination, then successfully moved the sub album sets/albums up into the new set, and finally deleted the problematical source album set. I didn't figure out why this occurred (I did another structure dump and everything looked OK).

2) Found the phplugins and custom.css problem that originally started this thread -- If I commented out the GET FUNCTIONS FROM WORDPRESS & SITE-WIDE NAVIGATION FROM WORDPRESS code in phplugins.php (see http://ce4.theturninggate.net/docs/doku.php?id=ce4_102) then every works fine. Again, this "crash" only occurs on my /galleries/ and /search/ pages (i.e., non-WordPress pages) and the error  message (see opening post in this thread) looks to me like WordPress widgets are trying to be called. Why would WP widgets be called on these non-WP pages? Did a WordPress sidecar template somehow get assigned to my publisher generated gallery and search pages? Anyway, I am temporarily working around this problem by doing site-wide navigation in a different way.

Thanks for your help, Ben & Rod!

Thanks, Ben! What do you mean by "page I messaged you" -- was this link sent by email? Or should I be looking somewhere else? In any case, I haven't seen anything yet with the necessary tool's link! (& I've checked my spam/junk email folders).

Thanks, Ben. I woke up this morning with two insights:

a) I had forgotten about the Publisher database -- that is, I hadn't thought to copied it over to the new website with the converted /galleries/. So, no wonder that things didn't "just work" after the conversion/migration!

b) I had forgotten that I had already learned to "touch" each and every album set/album in the copied-over /galleries/ before republishing a portion. That is, within Lr I had to perform an "edit album set" or "edit album" on each such in the migrated /galleries/ before I could republish it in the new website. That is, I simply had to open an edit dialog on each album set/album and save it. I'm guessing that by doing this that I was rebuilding/resync'ing the Publisher database between Lr and the server. Of course it is a PIA to have to walk the /galleries/ tree doing this "touching", but still a hell of a lot less work than having to regenerate each album set/album from scratch. Anyway, I just successfully did this "touching" on another big portion of the migrated /galleries/ and I am in the middle of a successful republishing of it right now.

So, at this point, it seems that we have two options:

1) restore everything to pre-migration (both server- and Lr-sides). I have Lr and server backups to do this, but it is going to take me into tomorrow to perform that work (FTP'ing-extracting-FTP'ing from a very large server backup). And then I'm still going to need some guidance in how to correctly move the newly converted /galleries/ to the new website. For example, I'll need instructions on how to move the publisher database and anything else connected. And, in the end, I may still have the same issue with my custom phplugins not working.

OR

2) disable phplugins and continue to "touch" and republish the migrated /galleries/.  Then start with an empty phplugins, see if that can be "linked in" without error. If it doesn't work, maybe you & Rod can help me get things working with that "empty" phplugins/custom.css? I think that I'll try this right now and see what happens...

Just replaced my phplugins with a new empty one from phplugins_sample -- converted, moved & republished album sets don't crash now. But they don't show a red background either. Don't have time to diagnose right now ... stay tuned. But it's looking to me that option #2 is going to be the best way forward ...

Sorry that it's so complicated, Ben ... To first give you some more context on why I am doing this -- I want to split my CE3 family website (samcos.com) into two websites: a Family website and a second Photography website containing only my personal stuff (under a new subdomain: rick.samcos.com). By far the largest part of the CE3 family website is its /galleries/ tree and the vast majority of it is my photography work which needs to go to the new photography website. In other words, I wanted to extract out my photography work out of the Family website's /galleries/ and put it into a new website. And I REALLY didn't/don't want to have to regenerate that part of /galleries/ structure in the new site.

With that context, let me now explicitly answer your 2 questions:

1) Yes, I performed the Publisher CE3->CE4 conversion at samcos.com/galleries/. I then FTP'd the result to my new, completely functioning CE4 website (i.e., to rick.samcos.com/galleries/); and then changed the same, converted Lr Publishing Service's url target to the new site. That is, I retargeted the exact same Lr Publishing Service that was the target of the CE3->CE4 conversion, to the new URL (and authenticated the Publisher API key). I then started republishing -- thinking that that would fix any broken connections. But, no, something remains broken.

2) No, I am not trying to use my CE3 version of phplugins at the new location. Rather, I have a completely fresh CE4 installation at the new domain, completely built from the ground up. That is, I constructed new CE4 templates (gallery, autoindex, and WordPress) and new custom.css/phplugins.php to give me a totally new CE4 website. And it was ALL working as I wanted using a smallish, dummy /galleries/ tree. That is, I had a completely new WordPress website with CE4 Templates and custom custom.css/phplugins.php  working/looking exactly as I wanted, except I didn't have my huge /galleries/ tree. That tree is just too onerous to regenerate, so I emptied the new site's dummy /galleries/ and copied in the CE3->CE4 converted tree from the original site. And I republished a portion of it and tried referencing it, and experienced the reported error.

BUT I don't get any errors if I remove my phplugins.php file! So the broken "Publisher Connections" only seem to be around that. Album sets/albums in the moved tree work fine (the ones that I  have republished). And the WordPress portion of the site is working fine. That is, everything except /galleries/ and /search/ are working, including use of the CE4 phplugins customization (e.g., dynamic mastheads). The /galleries/ & /search/ just can't seem to "hook into" the phplugins customizations, I'm thinking.

If what I did was a no-no, please tell me how I can replicate a /galleries/ between two targets. TIA!

Thanks, Rod, that did it!

Ummmm, you're right, Rod. Right after I reported this "problem" I found that some of my dynamic masthead display size breakpoints in my custom.css file weren't working within Publisher managed albums/sets, so I reverted back to an earlier version. That fixed the size breakpoint problems, and must have fixed WordPress's use of that custom.css file as well. I now suspect that I had a syntax error in my custom.css which caused WordPress to abort its interpretation and fall back to the dynamic masthead imaging that I had set up within WP itself.

Bottomline, sorry to have bothered you with this ... and onward!

Oh, you probably mean within Lr -- yes, in the Theme for WordPress template, phplugins is enabled and path is same as used in autoindex and gallery (which is working for those templates).

Thanks, Rod. Actually I already had dynamic mastheads fully working in autoindex, gallery & search. But when I then "turned on" WordPress its pages/blog didn't inherit any of it. So I guess that my question really is: how do I get WordPress to use my CE4 dynamic mastheads?

Of course, the AutoIndex-created /galleries/ directory doesn't show breadcrumbs. This is fine with me, but I wanted to point that out to others who may read this thread. I suppose that custom phplugins can be used to show them if desired (e.g., see http://danielleu.com/blog/2014/08/breadcrumbs-ce4/ ).