Thread

Attempted to sync images after upgrading to EE 2.2.1 and received error message for most images:

Images Exceed Max Size. However, maximum image width is set at 1,000 pixels, and no images are even close to that size. So, I set the maximum height of images to 1,000 (previously was blank) and the sync worked, and files are visible in File Manager.

Apparently, both a width and height are required to sync images, right?

However, at least one image is missing from the Corporate Theme, specifically:

http://mysite.com/themes/cp_themes/corporate/images/icon-image.png

That leaves a hole in the listing. The icon-image.png file is in the Default theme, and copies over OK.

UPDATE: Also, the File Manager gives all the images the same date, and puts them in reverse order, oldest images on top, newest images on the bottom. Any way to correct that mess?

Hi grrramps,

Couple of things going on here. First, I filed a bug report to let our devs know that the image was missing from the corporate theme. Find that bug report here.

The date listed in the File Manager is the timestamp from either the sync or the file upload (if the file was uploaded through EE). That’s why files synced together all have the same date attached to them.

Regarding the first issue in your post, I’m able to upload images of all sizes without both width and height declared explicitly in the upload directory preferences. Could you give me some more details and walk me through the steps necessary to replicate your issue?

Thanks, Kevin.

Couple of things going on here. First, I filed a bug report to let our devs know that the image was missing from the corporate theme. Find that bug report here.

Looks good. Easy fix.

The date listed in the File Manager is the timestamp from either the sync or the file upload (if the file was uploaded through EE). That’s why files synced together all have the same date attached to them.

All files were uploaded through EE over the course of seven years, and, of course, all the files have different dates. EE applied the same date stamp (and, nearly the same time) to all of them when synced.

I’m able to upload images of all sizes without both width and height declared explicitly in the upload directory preferences. Could you give me some more details and walk me through the steps necessary to replicate your issue?

I’ve had no problem uploading files for years with only the width declared in the upload directory preferences (on multiple EE installs, including 1.7.x and 2.x). The sync error was easily fixed by simply adding a height limit. I recently updated three sites to EE 2.x, and the sync on each failed until I added a height declaration. The sites have been running for years.

That brings up a separate issue (already filed in Feature Requests, whereby EE rounds off the width of an image when resizing proportionally. Web pages being what they are, the height pixels should be rounded off, instead of the width. I believe that’s the way it works in EE 1.7.x

All files were uploaded through EE over the course of seven years, and, of course, all the files have different dates. EE applied the same date stamp (and, nearly the same time) to all of them when synced.

So every time you sync files in a particular upload directory, those files’ timestamps are all reset to the current time? I’m not able to replicate this on my end, so it’s definitely not expected behavior. Am I understanding you correctly here?

I’ve had no problem uploading files for years with only the width declared in the upload directory preferences (on multiple EE installs, including 1.7.x and 2.x). The sync error was easily fixed by simply adding a height limit. I recently updated three sites to EE 2.x, and the sync on each failed until I added a height declaration. The sites have been running for years.

This is not expected behavior either. I’m not able to replicate this on my end since I have no value set in my height limit and I’m able to sync the files just fine. Could you zip up a few of the images you’re using that exhibit this issue and send them to me? Be on the lookout for an email from me, and you can just respond to it with the zip.

That brings up a separate issue (already filed in Feature Requests, whereby EE rounds off the width of an image when resizing proportionally. Web pages being what they are, the height pixels should be rounded off, instead of the width. I believe that’s the way it works in EE 1.7.x

I agree with you there, that’s probably a better behavior for the File Manager. Thanks for filing the feature request for it.

So every time you sync files in a particular upload directory, those files’ timestamps are all reset to the current time? I’m not able to replicate this on my end, so it’s definitely not expected behavior. Am I understanding you correctly here?

Yes. I did it on three installs (upgrades to EE 2.2.1) with the same result. The time stamp was not of the image time stamp, but of the current time.

Hi Ron,

I took a look at the File Manager screen you sent me, and that looks like the expected behavior to me. From what I’m seeing, there are different timestamps for different groups of files all within the same Upload Directory. Correct me if I’m wrong, but is the behavior you’re experiencing described like this?

- When you add 5 new images to the actual FTP directory (in other words, you don’t upload them through EE), and then sync them, those 5 files are given the same timestamp, which is the time of the sync itself.
- The other images in that same upload directory that were already listed in File Manager maintain their timestamp, which was given to them either when they were uploaded through EE or synced.

Correct? In other words, new files being synced are given the timestamp of the sync, but files that already exist in the File Manager are left alone. If so, that’s the expected behavior.

Now regarding the issue that required you to set the image height, in order to test that, I need some sample images that you tried to upload that required you to set “height” explicitly before they could be successfully uploaded. Could you please zip those up and send them to me?

I took a look at the File Manager screen you sent me, and that looks like the expected behavior to me. From what I’m seeing, there are different timestamps for different groups of files all within the same Upload Directory. Correct me if I’m wrong, but is the behavior you’re experiencing described like this?

- When you add 5 new images to the actual FTP directory (in other words, you don’t upload them through EE), and then sync them, those 5 files are given the same timestamp, which is the time of the sync itself.
- The other images in that same upload directory that were already listed in File Manager maintain their timestamp, which was given to them either when they were uploaded through EE or synced.

Correct? In other words, new files being synced are given the timestamp of the sync, but files that already exist in the File Manager are left alone. If so, that’s the expected behavior.

Sorry, Kevin, I’m lost.

Expected behavior is that the sync should take the time date stamp of the file and use that. In this case, all the files were added via EE, not via FTP, and uploaded through EE over the course of six or seven years.

So, what you’re saying is that files already added to EE’s uploads over the years, when synced, get the sync time date stamp, and not the image files original upload time date stamp.

If so, that’s rather goofy behavior, and seems to render the File Manager almost useless for those previously uploaded images.

Now regarding the issue that required you to set the image height, in order to test that, I need some sample images that you tried to upload that required you to set “height” explicitly before they could be successfully uploaded. Could you please zip those up and send them to me?

None of my EE sites, prior to upgrading to EE 2.2.1 had an image height set in preferences. When doing the sync in File Manager, the sync failed because of the aforementioned error. When adding a height limit, the sync worked OK. The images I sent you were part of that group that failed.

I took a look at the File Manager screen you sent me, and that looks like the expected behavior to me. From what I’m seeing, there are different timestamps for different groups of files all within the same Upload Directory. Correct me if I’m wrong, but is the behavior you’re experiencing described like this?

- When you add 5 new images to the actual FTP directory (in other words, you don’t upload them through EE), and then sync them, those 5 files are given the same timestamp, which is the time of the sync itself.
- The other images in that same upload directory that were already listed in File Manager maintain their timestamp, which was given to them either when they were uploaded through EE or synced.

Correct? In other words, new files being synced are given the timestamp of the sync, but files that already exist in the File Manager are left alone. If so, that’s the expected behavior.

Sorry, Kevin, I’m lost.

Expected behavior is that the sync should take the time date stamp of the file and use that. In this case, all the files were added via EE, not via FTP, and uploaded through EE over the course of six or seven years.

So, what you’re saying is that files already added to EE’s uploads over the years, when synced, get the sync time date stamp, and not the image files original upload time date stamp.

If so, that’s rather goofy behavior, and seems to render the File Manager almost useless for those previously uploaded images.

I think we’re seeing different things here. Here’s what I’m seeing from the zip file you sent me: I’m seeing a bunch of different files in the same upload directory with a variety of different timestamps. From that, I gather than syncing that directory doesn’t cause all files in that directory to reflect the same timestamp (that is, the timestamp of the sync). It appears that syncing only applies a current timestamp to the files that are new and therefore being added to the EE file manager.

Now, somewhere down the list of files, they all begin having the same timestamp: 2011-07-26 07:25 PM

I suspect those files are the ones you’re referring to, correct? I’m guessing those files were added to EE before the upgrade to 2.2 (in other words, before the new File Manager was introduced), correct? If that’s the case, they were all assigned that same timestamp when their file information was added to the DB. Before 2.2, file information was not stored in the DB, but was gathered from the filesystem itself. When you add new files using the EE File Manager—and by that I mean add files to the EE database through the new File Manager—it’s done by syncing those files. If a file doesn’t already have an existing record in the EE database, syncing that file will add it and give it the timestamp of ‘now’. That’s why the files uploaded to EE before 2.2 all have the same timestamp. They were, essentially, all added to EE’s File Manager database at the same time. Does that make sense?

Moving forward, uploading files and syncing them will only apply a timestamp of ‘now’ to new files being added, so you don’t have to worry that this is something that will happen again in the future.

Now regarding the issue that required you to set the image height, in order to test that, I need some sample images that you tried to upload that required you to set “height” explicitly before they could be successfully uploaded. Could you please zip those up and send them to me?

None of my EE sites, prior to upgrading to EE 2.2.1 had an image height set in preferences. When doing the sync in File Manager, the sync failed because of the aforementioned error. When adding a height limit, the sync worked OK. The images I sent you were part of that group that failed.

You didn’t send me images to test with earlier. You sent me Safari Web Archives of the EE File Manager and the web-based file manager for your server’s file system. I cannot retrieve images from either. Could you please zip up some of the files that are causing you trouble in order for me to troubleshoot the height requirement issue you’re having?

Here’s what I’m seeing from the zip file you sent me: I’m seeing a bunch of different files in the same upload directory with a variety of different timestamps. From that, I gather than syncing that directory doesn’t cause all files in that directory to reflect the same timestamp (that is, the timestamp of the sync). It appears that syncing only applies a current timestamp to the files that are new and therefore being added to the EE file manager.

Now, somewhere down the list of files, they all begin having the same timestamp: 2011-07-26 07:25 PM

I suspect those files are the ones you’re referring to, correct? I’m guessing those files were added to EE before the upgrade to 2.2 (in other words, before the new File Manager was introduced), correct?

Correct and correct. New files added via the File Manager get an actual time date stamp when the file is uploaded. Previously uploaded files, when synced with File Manager in EE 2.2.1, all receive the same time date stamp of the sync, and the time date stamp of the file is not used.

Moving forward, uploading files and syncing them will only apply a timestamp of ‘now’ to new files being added, so you don’t have to worry that this is something that will happen again in the future.

Yes. My concern was that the files previously uploaded through EE had specific time date stamps related to their actual upload time and date, which is not reflected when the first sync to EE 2.2.1 File Manager takes place. That renders EE’s File Manager more difficult to use for older files (but OK for recently uploaded files).

Was it not possible for the File Manager, during the sync process, to read the time date stamp of the files, and apply that to the database?

Now regarding the issue that required you to set the image height, in order to test that, I need some sample images that you tried to upload that required you to set “height” explicitly before they could be successfully uploaded. Could you please zip those up and send them to me?

That one is pretty much a moot point if all that’s required is a maximum height for the File Manager sync to occur. I added a maximum height and the File Manager synced the files (except for the time date stamp).

Hi, Ron. I can ask Robin about the date/time stamp and older images. As far as the zip file to demonstrate the maximum height issue, did you ever send that to Kevin, and do you want to peruse it further?

Ron. I can ask Robin about the date/time stamp and older images.

That’s one of those things that should be done a certain way. When images are synchronized to EE, they should carry over the image’s own time date stamp. Otherwise, finding images in File Manager is a royal pain, except for the most recent images.

As far as the zip file to demonstrate the maximum height issue, did you ever send that to Kevin, and do you want to peruse it further?

I don’t see that as much of an issue, unless EE has a problem and just won’t do syncs without a width and height parameter in settings. As always, width is more important than height. All I could send would be a bunch of images with varying widths and heights.

I’d much rather see effort put into EE 2.x to have the same image handling features that already exist in EE 1.7.x. Pop ups, portrait rounding instead of landscape rounding, thumbs and originals, etc.

I can completely understand your point of view here, Ron. You make a good case. I’m not sure about the technical limitations of doing so, and that may have been why the developers made the decisions they did when building the new File Manager. I can tell you, however, that it’s working as intended. I would recommend posting these suggestions over to the Feature Request forum since that’s a primary place we look for user input when improving ExpressionEngine.

Is there anything else we can help you with in terms of technical support?

I can tell you, however, that it’s working as intended.

So, to be clear, ‘as intended’ means ‘not as user might expect?’ Those image time date stamps are important to the user. When 99-percent of them are the same (after an initial sync), there’s little value in time date stamps until new images are uploaded. Sorting and finding images is a pain.

I would recommend posting these suggestions over to the Feature Request forum since that’s a primary place we look for user input when improving ExpressionEngine.

Understood. And that’s the case for requesting features that used to be in EE but no longer are?

Is there anything else we can help you with in terms of technical support?

You did good, Kevin. Thanks.

Honestly, I don’t go out of my way to find these things. My remaining EE sites are relatively simple setups. Users access only basic features, but these are easy finds.

I can tell you, however, that it’s working as intended.

So, to be clear, ‘as intended’ means ‘not as user might expect?’ Those image time date stamps are important to the user. When 99-percent of them are the same (after an initial sync), there’s little value in time date stamps until new images are uploaded. Sorting and finding images is a pain.

Right, in this case, it just means that it works as the developers intended for it to work when they built it. That doesn’t mean it’s necessarily the best user experience, of course. It just means it’s not a bug. I’ll make sure James sees this thread. UX is kind of his thing. 😊

I would recommend posting these suggestions over to the Feature Request forum since that’s a primary place we look for user input when improving ExpressionEngine.

Understood. And that’s the case for requesting features that used to be in EE but no longer are?

Yes indeedy.

Is there anything else we can help you with in terms of technical support?

You did good, Kevin. Thanks.

Honestly, I don’t go out of my way to find these things. My remaining EE sites are relatively simple setups. Users access only basic features, but these are easy finds.

Oh, no worries! Our chief goal is to give EE the best user experience possible. That doesn’t mean we’ll always agree on what that looks like, but it does mean that we want to hear what you have to say, and we’ll always take it seriously.

And just to affirm Kevin’s explanation- the sync (and the upload) putting the file date as the time of the sync for newly imported files is intentional.  That said?  We intend to add a hook to allow the easy manipulation of that data, as there are a lot of things folks might want to do - pull date from exif, from the file date, create a title on the fly based on some manipulation of the file name, etc.

Once the hook is there?  There will be the flexibility to configure things in a much more site specific way.  ‘Date of sync’ is just the default we went with as one of several options that all made sense.

And grrramps?  If the behavior is totally jamming you, let me know and I could likely write up a quick hack that would use the file date. 

Oh- and I believe there was a bug in some of the image resizing- in all cases, you should be able to specify either height or width- and doing so makes that the ‘master dimension’.  That should be the case in 2.2.2 as I believe that tweak made it in.