lschiffli

Yes, I am still getting “There was an error rendering the field” on date/time fields when editing PODS on iPad with both Chrome and Safari. I have updated to 2.8.7.

Here is how I have the date/time field configured.

https://test.recklesssaints.com/files/concert_date_time_field_details.png
https://test.recklesssaints.com/files/concert_date_time_options.png
https://test.recklesssaints.com/files/concert_date_time_advanced.png
https://test.recklesssaints.com/files/concert_date_time_REST_API.png

I have a similar issue with custom date/time fields on 2 different sites; however, I am only getting the “There was an error rendering the field” error when adding or editing a Pod on an iPad. My client updates the custom Concerts pod on an iPad. I can reproduce the problem with both Safari and Chrome on 2 different iPads. The site is running Pods 2.8.5. I *do not* get the error on the sites from Windows 10 Chrome, Edge, and Firefox.

@rwattner – I sent you an email with more info on this issue. Please check your gmail account. Thx.

After doing some more investigation, I think I’ve discovered the issue here. There are changes between version 1.3 and 1.4 on calculations with Shrink Header/Header Height and Logo Height. I had to make some adjustments in my settings with version 1.4 to get the same results as I had with version 1.3. After making those adjustments, I no longer have the width: 0px; issue, so I suspect it’s an occasional issue that occurs depending on Shrink Header settings.

@mrvly – I suggest you check those settings and make sure that the size of your logo after the shrink percentage is not larger than the entered Shrink Header Height. Note the Shrink Header Height is in px and the Logo Height size is %.

• This reply was modified 4 years, 1 month ago by lschiffli.

I have this same problem also. (Chrome 85 official) As I start to scroll, the logo image style is changed to width: 0px;

<div class="elementor-widget-container">
  <div class="elementor-image">
   <a href="https://   etc.>
     <img  etc. style="transition: all 0.4s ease-in-out 0s; />

That last style tag is being dynamically changed when scrolling begins to:

style="transition: all 0.4s ease-in-out 0s; width: 0px;"

That width: 0px; is causing the logo image to vanish.

I came to this forum because I also have other breaking issues with the 1.4 update that disappeared when I reverted to the 1.3.2 version. I have multiple staging sites where I can demonstrate the problems. I have tracked down at least part of the problems, and I’m still investigating. I would be happy to send you the links.

• This reply was modified 4 years, 1 month ago by lschiffli.
• This reply was modified 4 years, 1 month ago by lschiffli.

The relative URLs worked with Elementor 2.9.10 and earlier. The breaking change is with the 2.9.11 update. (I was able to test this on a staging site that hadn’t updated to 2.9.11 yet.) Version Control under Elementor/Tools has a rollback to 2.9.9. but not 2.9.10.

I’m experiencing the same issue on two sites that previously worked.

There’s a current problem with Dropbox backups. Updraft does not delete all the files in a backup when automatically deleting the oldest backup (ie. Retain this many scheduled backups – under Settings). Some of the backup files are not deleted from Dropbox, so you need to log into the Dropbox account and manually delete them occasionally to keep it from filling up until this bug is fixed. (There’s another detailed support thread in this forum about this issue.)

Thanks, @rmr65 for the update on Google Drive. I’m sticking with Dropbox for now and manually deleting the leftover files every few days although that can only be temporary. I am however, becoming increasingly concerned about the lack of response to this issue even in light of the pandemic.

The delete from Dropbox DOES delete all 5 of a backup’s files when you click on the red “Delete” button under the Actions column on the UpDraft Existing backups dashboard.

It still does not delete all files during the automatic excess versions cleanup step in a new scheduled backup as documented in above posts.

Please fix this bug.
Thank you.

I just checked another site and it has the same problem also.

I’m having this exact same problem also with the same pattern reported in the log file as others have posted.

When the max number of retained database backups is reached, it is correctly deleting the oldest database backup.

HOWEVER, when the max number of Files is reached, ONLY the “backup_…-plugins.zip” file is actually deleted from Dropbox. The themes, uploads, and others zip files are remaining left behind on Dropbox and therefore causing Dropbox to fill up unless they are manually deleted from the Dropbox site.

My server is running PHP 7.3, and Updraft, WordPress and all plugins and theme are up to date.

Please help. Thank you.

(Relevant log file excerpt.)
0061.306 (0) plugins: over retain limit (8); will delete this file entity
0061.306 (0) themes: over retain limit (8); will delete this file entity
0061.306 (0) uploads: over retain limit (8); will delete this file entity
0061.306 (0) others: over retain limit (8); will delete this file entity
0061.306 (0) Delete file: backup_…plugins.zip, service=dropbox
0061.307 (0) Delete file: backup_…themes.zip, service=dropbox
0061.309 (0) Delete file: backup_…uploads.zip, service=dropbox
0061.311 (0) Delete file: backup_…others.zip, service=dropbox
0061.314 (0) Dropbox: request deletion: backup_…-plugins.zip
0062.155 (0) Dropbox: delete succeeded
0062.163 (0) This backup set is now empty; will remove from history
0062.166 (0) Deleting log file (log.a965de168ddb.txt)
0062.168 (0) Retain: saving new backup history (sets now: 8) and finishing retain operation