|
Dave Bell
|
November 30, 2012 at 1:49 pm
Hi Support. I just set up a new installation of Event Espresso on http://www.polkadotpalette.com/calendar. As you can see in the month of December, if I have multiple images on a given day, they can overlap across each other and across days. [BTW, I’m using Chrome – looks like IE doesn’t have this problem all the time, but I have seen it in IE as well]
This is identical to a problem in a previous post: https://eventespresso.com/topic/calendar-images-overlap/
I deactivated all non-EE plugins and the problem remains.
If you see the error and then Refresh the page and go forward to December again, the problem will be resolved.
I joined VIP in hopes of maybe getting access to a beta that resolves this issue, but I can’t figure out where to go to get the beta access.
Please help if you can. Thanks.
|
|
Dean
|
December 3, 2012 at 1:16 am
Hi Dave,
Using Chrome to check your site, the images overlapped for a second or so as the calendar loaded and then sorted themselves out, same in IE.
Are you using the latest version of EE and the Calendar add on?
All the current betas and pre releases are here https://eventespresso.com/support/documentation/pre-release-downloads/
|
|
Dave Bell
|
December 5, 2012 at 12:04 pm
I am only seeing this problem in Chrome, and not on IE.
The issue appears to be on the second month. When I started this thread it was November 30th, so November looked fine but clicking the next/right arrow showed the problem on the month of December. Now that we’re in December, December looks fine but January shows the overlap. Again, hit the refresh button and the problems go away. Please check http://www.polkadotpalette.com again and go to the calendar and January using Chrome to verify for yourself.
If I had to guess, it seems like there is some code that gets run after the initial calendar layout to resize things and fix the overlap problems. However, this code doesn’t get executed when you go to the ‘next’ month using the navigation arrows. Might that be possible?
|
|
Dean
|
December 6, 2012 at 12:42 am
Hi Dave,
Yes I see it now, this should have been resolved already. Are you using the latest version of the calender add on?
|
|
Dave Bell
|
December 6, 2012 at 5:52 am
Yes, I’m running EE 3.1.28.5.P and Calendar 2.0.4
|
|
Dean
|
December 6, 2012 at 12:11 pm
Hi Dave,
I had a discussion with some of the support/dev staff on this. It is a known issue but one that is hard to resolve. What we believe is occurring is the page is getting cached in the browser and on subsequent visits it is interpreting the cached info wrong causing the overlap (this is why I didnt see it at first, it wasnt cached).
WE are currently looking into replacing the whole structure of the calendar, until then there is little to resolve this except:
1) Stop caching on that page – http://creativedev.in/2012/02/to-prevent-caching-in-web-browser/ – this will slow the load time down, by how much is difficult to say, just be careful to limit it to the calendar page only.
2) Roll back the calendar plugin/full calendar version (which removes the images) or turn off the images on the calendar.
I am sorry I can’t give you a better resolution to this currently.
|
|
Dave Bell
|
December 6, 2012 at 1:51 pm
Thank you for your response. I’m hoping you will continue to
investigate this issue.
I just visited the site on a brand-new machine which had never been to
polkadotpalette.com. Again, the December calendar comes up fine, but
going to January shows overlaps on some classes. Thus, it is not a
caching issue per se that only occurs when revisiting the page.
This is going to get very bad for my customers as we get later in
December and the January month is filled out.
Please keep me informed as to whether or not you have other
suggestions or alternatives. Thanks.
|
|
talves
|
December 20, 2012 at 2:24 pm
Have to concur with Dave here… We are seeing the same issue and it is definitely not a cache issue.
Our client is an art studio who depends on images on her calendar to draw customers. Up until the WP 3.5 update we have been using a dev issue of your plugins that we tweeked to get images to show correctly. 3.5 rendered them unusable however leaving us in the same boat.
We have been waiting for EE 3.2 and working images on the calendar for a year now. Have we been holding our breath for nothing?
|
|
Josh
|
December 20, 2012 at 4:02 pm
Hi there,
I’m sorry for all the trouble that you’re having with the calendar thumbnail images. The reason that the old calendar broke with the update to WordPress 3.5 is that 3.5 includes a newer version of jQuery. We updated the calendar plugin’s JavaScript to be compatible with the new version, and we can do the same for the dev copy that you tweaked. Do you have the code posted somewhere so we can take a look at it?
To be honest, the calendar that shipped with thumbnails was going to be the new calendar with 3.2. There have been delays with 3.2, so 3.1 was modified to use the new calendar.
|
|
talves
|
December 20, 2012 at 5:44 pm
Which code would you need? The JS for the calendar I am using?
|
|
Chris Reynolds
|
December 27, 2012 at 2:46 pm
The calendar javascript was updated because the WordPress 3.5 update updated the version of jQuery included with WP. The latest fullcalendar.js has fixes that address this. If that’s the issue you’re having, you should just be able to swap out the fullcalendar.min.js in the espresso-calendar/scripts folder with the updated version here.
That said, I can’t guarantee it will work with the versions you are using, since it would depend at what point you started making changes to the code.
|
|
Dave Bell
|
December 27, 2012 at 4:12 pm
No, I’m still using WordPress 3.4.2. Would upgrading to WordPress 3.5 potentially fix the problems I am seeing?
|
|
Chris Reynolds
|
January 1, 2013 at 12:43 pm
@Dave The overlapping images issue is a known bug and there is no fix at this time. We are looking at new calendar systems or possibly building our own but that is a longer-term solution. The only workaround at this time if you are experiencing overlapping images is to not use images in the calendar, use images in the description instead of the featured image and display tooltips (so the image appears in the tooltip popup), or only use a single image for an event for each day rather than having an image for every event that occurs on the same day.
My previous comment was directed at @talves.
|
|
Greg Davis
|
January 14, 2013 at 7:03 pm
@Dave – I noticed the calendar on your site seems to have the issue resolved. Can you share what you did to fix it? I’m seeing the same problem of overlap on the same day events (with images) and would like to correct it as well.
Thanks!
Greg
|
|
Jesse Perry
|
January 14, 2013 at 7:26 pm
Yeah, I am interested too. I am having the same problem with one of my site. I tried to backdate the calendar but it doesn’t seem to work with the newest version of WordPress. What did you do to fix your overlapping issue?
Visit the site I am working on at http://fullthrottleacademy.com to see mine overlapping. Thanks! This happens on both the main page and the calendar page.
|
|
Dave Bell
|
January 16, 2013 at 8:03 am
Hi Greg and Jesse. I’m afraid that the problem is not fixed on my site. It seems that if there are only a few days on the calendar that have double-images in a single day then it might work, but if you fill out a full month and ESPECIALLY if you start to add classes in the next month which show up at the bottom of the current month – then you’re going to have overlap.
I’m a little disappointed that the only ‘workarounds’ suggested are to not use images in the calendar. That’s not an option for my client. These calendar images are THE REASON I chose Event Espresso, and I hope you guys will work on this bug instead of just putting it off to the next major release of the calendar.
I’ve resorted to adding text at the top of the calendar: “NOTE: if you see overlapping calendar entries, please go back or forward one month and then return to this month”.
|
|
Garth
|
January 31, 2013 at 6:02 am
Hi Dave,
What are your thoughts on what this Event Espresso user has done with the calendar: http://4theloveofsewing.com/wpsite/schedule/
We’re discussing internally adding their modifications to the calendar.
|
|
Dave Bell
|
January 31, 2013 at 7:35 am
It looks ok and I assume it works well for their needs, but our customers are selecting a class on the calendar based upon what painting they will be working on, so the calendar must show the images without requiring mouseover. Too much to expect a customer to mouseover 20 to 30 days just to see what the painting looks like.
The current calendar is very much what I want – it just has a bug. Is fixing this bug completely off the table?
|
|
Chris Reynolds
|
February 4, 2013 at 12:51 pm
@Dave We’ve spent months trying to fix this bug. The main issue is that we’re trying to make the calendar do too many things simultaneously. It would require one of the following options to solve the problem:
a) Devoting even more time than we already have into a solution. Again, this is something we’ve already looked at a number of times without 100% success.
b) Completely rewriting the entire calendar plugin, using the current fullcalendar.js script, from the ground up. (I should note that I’m not entirely sure this would even work, which would mean even more time devoted to something that was ultimately a bust. But I can say that I’ve seen similar implementations of fullcalendar.js to what we’re trying to do — however, what I’ve seen were for instances when there was only one event per day, and we need to support multiple events, each with an image per day)
c) Building an entirely new calendar with either a custom built calendar solution developed in-house or a different, existing library other than fullcalendar.js.
So, it’s not entirely off the table per se. But there isn’t a lot of incentive in paying our dev team for hundreds more hours working on this when we have other things — like Event Espresso 3.2 — that they are currently working on with a higher priority. We really thought, when we released the last update to the calendar, that we finally got it nailed. It worked in testing in a variety of different environments. Unfortunately, it has to do with multiple things happening when the page loads and the javascript executes and it has to do with the timing of each of those things, which is much trickier to deal with with javascript than it is with PHP.
The way the fullcalendar.js script works is it builds the table for the month. It loads the events in an array. Then, after the calendar is loaded, it adds a bunch of <div>s at the bottom of the page, and positions them and resizes the rows in the calendar dynamically based on calculations it makes based on the content of each event. The problem exists because when it makes those calculations, it makes the wrong calculations which is why I don’t think the calendar script is suited for this task and why I say we’re trying to make it do more than it was built to handle. For some reason — possibly because the whole series of events and event content has loaded — when you go to the next month and back, and it reloads the images, it loads them correctly. So it’s obviously able to do the right calculation, but what is making it do the wrong calculation has been the subject of our months of development and working on this.
Does that make more sense?
|
|
Dave Bell
|
February 4, 2013 at 2:14 pm
Hi Chris. My sincere thanks for your response, and please know that as a software product manager for many years I can understand hard-to-fix bugs as well as the prioritization of other items in the queue. I am (somewhat) comforted to know that you have investigated it and that you have communicated with us honestly. I will still hope for a fix in the future. If there is anything I can do to help test and/or debug the situation, please let me know. As you point out, it is ‘able’ to do the right calculation, but on first run it makes the ‘wrong’ calculation. It is this fact, that it is “so close yet so far”, that makes this particularly frustrating.
Again, thanks.
|
|
Chris Reynolds
|
February 5, 2013 at 1:33 pm
I agree. Our last pass was thinking that maybe it had to do with the time it took for the images to load, so we added a pause action before the rows were sized. Unfortunately, that didn’t do the trick, either, so we’re sort of back at square one.
|
