Support community for TTG plugins and products.
NOTICE
The Turning Gate's Community has moved to a new home, at https://discourse.theturninggate.net.
This forum is now closed, and exists here as a read-only archive.
You are not logged in.
After performing a CE3->CE4 /galleries/ conversion and then moving the resulting /galleries/ to a new CE4 website, the moved album sets and albums generate the following error:
include_once(/addtoany.widget.php): failed to open stream: No such file or directory|#0 /home/rsamco1/public_html/_sites/rick/wp-content/plugins/add-to-any/add-to-any.php(1070): ErrorHandler::handleError(2, 'include_once(/a...', '/home/rsamco1/p...', 1070, Array) #1 /home/rsamco1/public_html/_sites/rick/wp-content/plugins/add-to-any/add-to-any.php(1070): A2A_SHARE_SAVE_widget_init() #2 [internal function]: A2A_SHARE_SAVE_widget_init('') #3 /home/rsamco1/public_html/_sites/rick/wp-includes/plugin.php(496): call_user_func_array('A2A_SHARE_SAVE_...', Array) #4 /home/rsamco1/public_html/_sites/rick/wp-includes/default-widgets.php(1420): do_action('widgets_init') #5 [internal function]: wp_widgets_init('') #6 /home/rsamco1/public_html/_sites/rick/wp-includes/plugin.php(496): call_user_func_array('wp_widgets_init', Array) #7 /home/rsamco1/public_html/_sites/rick/wp-settings.php(353): do_action('init') #8 /home/rsamco1/public_html/_sites/rick/wp-config.php(92): require_once('/home/rsamco1/p...') #9 /home/rsamco1/public_html/_sites/rick/wp-load.php(29): require_once('/home/rsamco1/p...') #10 /home/rsamco1/public_html/_sites/rick/phplugins/phplugins.php(23): require_once('/home/rsamco1/p...') #11 /home/rsamco1/public_html/_sites/rick/ttg-be/templates/autoindex/TTG_CEx_AutoIndex/template_index.php(19): require_once('/home/rsamco1/p...') #12 /home/rsamco1/public_html/_sites/rick/ttg-be/publisher/application/controllers/GalleryController.php(181): include_once('/home/rsamco1/p...') #13 [internal function]: GalleryController->autoindex('', 'index', '') #14 /home/rsamco1/public_html/_sites/rick/ttg-be/framework/controllers/Controller.php(41): call_user_func_array(Array, Array) #15 /home/rsamco1/public_html/_sites/rick/ttg-be/framework/Framework.php(124): Controller->dispatch(Array) #16 /home/rsamco1/public_html/_sites/rick/galleries/Rick/i-2014/c-S-Utah-N-Arizona/lib.php(48): Framework->route() #17 /home/rsamco1/public_html/_sites/rick/galleries/Rick/i-2014/c-S-Utah-N-Arizona/index.php(4): route(Array) #18 {main}|URL: /galleries/Rick/i-2014/c-S-Utah-N-Arizona/index.php
Here's the broken website's /galleries/ url: http://rick.samcos.com/galleries & this subtree within it has been completely republished: http://rick.samcos.com/galleries/Rick/i-2014/ (the original source CE3 website, now with an empty /galleries/, is at samcos.com).
If I temporarily remove /phplugsins/phplugins.php from the server then the album sets/albums display correctly (albeit with none of my careful custom formatting). So IMO something is broken in the linkage between the site's custom php/css and these converted & moved /galleries/. I have checked the paths shown in the error message and they are all correct (the referenced files are at those locations). Here's what /phplugins/path.php returns: "/home/rsamco1/public_html/_sites/rick/phplugins".
The converted /galleries/ were moved into a target /galleries/ directory that just had a completely working, Lr publisher-managed /galleries/ tree. So the CE4 templates being used have the correct phplugins path (and I later reinstalled them just to be safe). The functioning target/destination /galleries/ tree had been deleted/emptied by deleting the album sets/albums using Lr. Nothing was touched anywhere else before the move (i.e., not in /phplugins/ or any WordPress configuration). The album sets/albums that are not working (see above) were republished by Lr after the move (it's a huge /galleries/ tree so it will be day or more before I am able to republish it all). I have made one change in WordPress after experiencing this problem -- I activated the CE4 WordPress template produced by Lr, thereby un-activating a child theme I had created (which had a single template override: loop.php).
Here is more detail on how I got to this point:
I carefully designed a new website UNDER A NEW DOMAIN and got WordPress, AutoIndex, & Gallery Templates, and custom css/php where I wanted them. Website completely functioned with a dummy /galleries/ tree. The CE4 AutoIndex & Gallery Templates were named exactly the same as used on my CE3 website.
I went to my CE3 website and installed CE4 ttg-be and publisher; installed the newly completed CE4 AutoIndex & Gallery templates from the new website into /ttg-be/templates/; set up a new CE4 Lr Publish Service containing no albums/album sets; made sure that my CE3 galleries were completely published; and ran the CE3->CE4 conversion plugin. It finished with a successful summary message.
I edited the new Lr CE4 Publish Service (the target of the conversion) to have a new API url and verified its key. I did NOT have it republish the tree when asked.
I copied the resulting converted /galleries/ tree to just-emptied /galleries/ tree in the new website (I confirmed it was first empty using FTP).
I published the /galleries/'s "Rick/i-2014" sub tree and experienced the above error when invoking any of its album sets/albums.
I'm stumped...
Last edited by rsamco (2015-02-09 12:12:42)
Rick
Offline
that was a lot to try to follow
when you say "performing a CE3->CE4 /galleries/ conversion and then moving the resulting /galleries/ to a new CE4 website, the moved album sets and albums generate the following error"
you performed the Publisher conversion on your Albums in one location? And then move the galleries/ folder to a new location? If so, that likely broke your Publisher connection. Ben will have to confirm.
and let me ask you this. Are you trying to use your CE3 version of phplugins with CE4?
page structures and classes have changes so things like navigation won't work from CE3 to CE4
Rod
Just a user with way too much time on his hands.
www.rodbarbee.com
ttg-tips.com, Backlight 2/3 test site
Offline
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!
Last edited by rsamco (2015-02-09 16:48:52)
Rick
Offline
After leaving all this for a few hours, I came back and now find that I can't republish any additional moved album sets! Whereas I successfully republished a couple big branches of the /galleries/ tree a few hours ago, now I can't publish any more. The error I experience is:
http://www.samcos.com/downloads/CE4_republish_error.JPG
So it look like the Lr publisher database really is screwed up now. In the morning I am going to restore Lr and my CE3 Family website to their states before the conversion so we try all this again.
So, the question is: how can one move a large /galleries/ from one functioning website to another? I guess alternatively: how can one replicate/copy album sets between separate Lr TTG_CE publishing services?
PS I noticed that there is a Lr Plugin called "TTG CE4 Publisher>>Output Publisher Structure" -- for curiosity's sake I ran it and received a completion message. But I can't find where the output was written.
Rick
Offline
I suggest you disable your phplugins and try migrating again. We cannot provide support for code you've added to phplugins.
The output publisher structure is a command that we sometimes ask customers to run in order to work out issues. The output is capture in a file called ttg.log, found in your Documents directory.
Offline
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 ...
Rick
Offline
The migrator function is meant to handle everything database-related. After migrating, the galleries directory should remain intact, with all ce3-specific files moved aside. For example the file galleries/galleries.xml is renamed to galleries_ce3.xml. At that point, the ce3 instance in Lightroom should no longer be able to manage anything under galleries on your server.
Have you changed the structure of the albums and album sets in either the ce3 or ce4 Lightoom publisher instances since migration?
Offline
Thanks, Ben. That's exactly what I thought, and what I am seeing, regarding the CE3->CE4 migration. I assume that I can safely delete the *_ce3.* migration files at some point, right?
To answer your question: I did change the structure of albums and album sets after migration, BUT only from within Lr. I "pruned" out some no longer wanted albums/album sets -- deleting each from within Lr, choosing to leave it published on the server, and then deleting that tree manually through FTP.
Here's where I am now: I completed the complete "touching" of all albums/album sets within /galleries/ (by manual using Lr to edit each one). I have also completely republished the entire /galleries/ tree. And, after all that, everything looked OK in (rick.samcos.com/galleries/)-- I could browse the album/album set tree without problem. So I think that everything has been migrated OK -- Yay! I still need to determine why phplugins isn't working, but first ...
<NOTE: I made a backup of both Lr's catalog and the server's complete website tree at this point>
The next step is to get rid of a no-longer-needed level within /galleries/. To explain, here's my /galleries/ structure at this point:
/galleries/
/Rick/
/a-Favorites (an album)
/i-2014/
/j-2013/
/k-2012/
/l-2011/
:
/t-2003/and I want to get rid of /Rick/ by promoting all if its yearly albums/album sets up a level -- so that they are residing directly under /galleries/. Here I ran into a problem which I seem to have rectified. But I want to make sure before I proceed any further.
I successfully moved /i-2014/ & /j-2013/ up under /galleries/ by just drag&dropping within Lr. But I received a publisher/server error when moving the next album set /k-2012/, and I couldn't do anything with that album set within Lr thereafter. Through FTP I saw that the directory had moved up a level, but Lr still showed it within /Rick/. So I manually moved it back down to its original location using FTP, hoping that that might fix the problem. At first it didn't seem to work -- I initially experienced a path not found publisher error when Lr edited that album set. But then I tried editing it again and everything then seemed to be OK?!?!?! But I am really uncomfortable proceeding any further with these moves for fear that the /galleries/ structure/database is getting messed up. And I don't want to try restoring my backups either for fear that the publisher's /galleries/ database on the server won't be restored since I don't know where it resides.
So, I think that I'll leave the /galleries/ tree as it is until I hear back that I can either (a) safely proceed with promoting the yearly album sets OR (b) restore everything to its earlier state (including the /galleries/ database, wherever it resides). (BTW, I have returned the two moved yearly album sets back down under /Rick/.)
Whew! Sorry for these long winded descriptions, but I am trying to be extremely careful so that I don't loose A LOT of work. TIA
Rick
Offline
It sounds like you're making progress. I've sent you a link to help check the structure of your galleries in Lightroom. It's a tool that I use to help solve issues like these. The idea is to compare this structure with what you're seeing in FTP.
To view the structure:
1. Run the command File -> Plugin Extras -> Output Structure (or similar name)
2. Find your ttg.log file under Documents.
3. There should be a line at the end with 'inspected' near the start. Copy everything from [[ to ]] including the square brackets.
4. Click on the Convert gallery... On the page I messaged you
5. paste the [[...]] text in
6. Visit the List gallery xml files link on the page I messaged you
7. Click View Structure on the most recent entry (probably with 20150211 in the name)
The number next to each can be ignored for now. If the structure matches what you're seeing in FTP then you should be fine. If not, please pass me your TTG admin login so that I can see if this can be fixed in the database. It would also help to have ftp access so that I can compare the file structure as well.
Offline
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).
Rick
Offline
if Ben messaged you, it's likely a PM. Look at the top right of the forum page for the letters PM if they are in bold, you have a message. Just click on it.
Rod
Just a user with way too much time on his hands.
www.rodbarbee.com
ttg-tips.com, Backlight 2/3 test site
Offline
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!
Last edited by rsamco (2015-02-11 10:58:20)
Rick
Offline