JoshTT35

I spent quite a bit of time trying to track down CSS using Firebug and was unsuccessful (prior to my post above), so I moved on to other issues for the time being. I’ll maybe post a link to something live when I get a chance. Thanks.

Update:

It appears my FTP client has a “Cache directory listings” option enabled. Perhaps that was the source of the issue.

Yeah, the renaming was not altogether unexpected, but since it was an old folder (before the renaming was instituted), I forgot that there were one or two direct links. But the real problem was that my FTP client wouldn’t initially recognize the new lowercase filename, despite closing/opening the program and refreshing the folder list multiple times, which made it appear that the folder was unchanged and the contents deleted, leading me to believe that my direct links were still legitimate but the source nonexistent (none of which was true; it only appeared that way for a time).

Eventually the FTP issue worked itself out to reflect the actual status of the folder name and files, but I’m not sure what happened to fix it, nor why it happened in the first place. Perhaps it’s a bug in the FTP client that caused the hiccup.

UPDATE #2:

Around midnight, I refreshed the CAD280 directory in the FTP client and it transformed to all lowercase cad280. Not sure if my host guy did anything at that point or if there was some automated server event going on that fixed the issue without intervention.

I know NextCellent has been renaming imported files to all lowercase, but until today I had not run into any problems with directories with capitals (if it was even related to that). I’ll have to do some testing on a throwaway gallery, but perhaps by importing files NextCellent also renamed the directory, causing a bit of a hiccup with the server.

Minor update… All my gallery images still load for viewing (I have not cleared the NextCellent cache), but not the PDF (not cached by NextCellent, obviously).

I’m attempting to re-upload my image files into the same directly, but my FTP client is telling me it doesn’t exist (I can see the folder clearly! and the file permissions are the same as everything else!)

The error message: 550 Can’t change directory to /web/wp-content/gallery/portfolio/CAD280: No such file or directory

I’m going to contact my webhost and update if something changes.

UPDATE: I can access image links directly via other browsers but not the PDF files; I am starting to think the images still exist but for whatever reason the FPT client isn’t giving me access to that folder and (for whatever reason) can’t display the PDFs by direct link.

Thanks for looking into it!

Josh T.

Cool. Thanks!

Thank you.

I just did a couple of trial imports on Localhost with apparent success. First I imported back into the source site. Then I exported/imported from Live to Localhost.

So I can’t repeat the error, and I still have no idea what caused it. It was very strange, and like I mentioned before, it happened a few weeks back as well as yesterday.

As for the error message itself, it is the exact same one you get if you click the import button without first browsing and selecting a wie file. It is as if it didn’t detect my selection: “You must upload a .wie file generated by this plugin.” Except that I had selected a file beforehand. I know this because yesterday I first clicked the import button, got the standard error message, then went back and browsed/selected my wie file, but then got the same error message after hitting import. I just tried to repeat the process out of order again (import-button/error/browse-button/select/import-button), but no second error–import went just fine.

Probably no big deal. Sorry I’m not able to help more.

Thanks for mentioning that 1.9.18 worked fine with nggtags; I only noticed accidentally while browsing my site after a theme update. I just reinstalled the older version for now, and it works fine. Hopefully the kind folks maintaining this NextCellent branch of the NextGen Legacy will be able to find and fix the shortcode issue shortly.

Can you verify that the file you were trying to import had a .wie extension in the filename?

That is correct. And the same error message happened a few weeks ago during a local test import. And in the case yesterday, the same .wie-generating plugin was used on both localhost to generate the file and the live site to attempt the import.

Thanks for considering it, Nirmal. ??

Update: At least in regard to the right-floated primary sidebar, the following CSS added to a child theme may do the trick for some to prevent overlap of the post content, though there may still be issues if a secondary sidebar is enabled. This at least takes care of the overlap that occurs when the primary sidebar narrows slightly, but before it switches locations (during browser resize to smaller window).

/*  RESIZE FOR RIGHT-FLOATED PRIMARY SIDEBAR  */
@media screen and (min-width: 1008px) and (max-width: 1079px {
#content.site-content article {
margin-right:182px;
}}

I’ll play with it and see where it takes me. In the meantime I’m sticking with the left bar, though my preference is for the right.

Thanks for the suggestion. It may be a while, so I’ll go ahead and mark this as resolved.

Josh T.

Let me add a correction. If the secondary sidebar is not active, the right-floated images within a post are NOT stopped by the right side of the page. In a more extreme case, if I widen the post content using a child theme/stylesheet, right-floating images will hang off the page (even if Primary sidebar is in the default left-hand position). The images will jump into proper position (aligned with text) only after significantly shrinking the window (to about 790px wide).

So the right-floated image problem seems to be caused by the theme itself, which may make it more difficult to get the responsive functionality of a right-floated primary sidebar to work well.

Example of images hanging-off the page after text widened for anyone curious: Screenshot