Home › Forums › Calendar Products › Events Calendar PRO › 3.2 upgrade breaks Infocus theme TimThumb image resizing
- This topic has 11 replies, 2 voices, and was last updated 12 years, 4 months ago by
Barry.
-
AuthorPosts
-
November 19, 2013 at 4:06 am #77270
kellyco
ParticipantHi,
Things were fine with 3.1, but upon upgrading to ECP 3.2 the timthumb resizing of images on my home page is now broken. There seems to be something that has changed in the script that prevents the timthumb call from within the InFocus Theme (mysitemyway.com) as the images no longer have the timthumb code included:
With ECP on I get this:instead of:
Can you point me in the direction of code changes in 3.2 that might be interfering with the theme’s calls to TimThumb image resizing?
November 20, 2013 at 5:52 am #77594Barry
MemberHi kellyco,
Unfortunately I can’t observe your site without a login ad it looks like the forum software has stripped out whatever code you posted (unfortunately, it’s pretty poor at handling posted code). Could you share that a second time but by linking to the same code on Gist, Pastebin, Droplr or a similar service?
Thanks (and sorry for the inconvenience)!
November 25, 2013 at 4:34 am #78424kellyco
ParticipantThanks for trying.
I was not sure if the code got stripped or was just private for admins – not sure it helped much anyway.
I have removed the requirement to be logged in to view the site.
As mentioned, things displayed fine on the home page with 3.1, but upgrading to 3.2 seems to have broken the image resizing. I think it is something that was changed in the main Events Calendar code rather than the Pro add-on because if I disable the pro bit things are still broken.
You can see what the images should look like by clicking on one of the posts – the detail blog post page resizes images correctly – it is just the home page that breaks. Not quite sure how to go about troubleshooting The Events Calendar plugin – I would normally start removing code until I found the problem area.
I have tried disabling all plugins and things work fine – then activating Events Calendar breaks things (even with all other plugins disabled) so some sort of conflict between the theme and Events Calendar seems to be the cause.November 25, 2013 at 1:52 pm #78480Barry
MemberI’m not at all sure why that would happen. Have you any settings enabled, such as the include events in main blog loop, that might impact on the front page and have you tried toggling them on/off?
November 27, 2013 at 3:58 am #78837kellyco
ParticipantThanks – tried that – no luck.
Turned it on, tested and then off and tested again. Didn’t make any difference.
Good suggestion though. Perhaps the code for the WordPress menu bar is interfering?
I wonder what else is being called by default? I thought it might have been a widget causing interference, but made sure I removed the ECP widget from the sidebar.
Any other thoughts on what might have changed been 3.1 and 3.2 that would interfere with TimThumb or javascript?November 27, 2013 at 8:21 am #78891Barry
MemberAfraid not, nor do I see any Javascript errors on your home page. Have you approached the theme vendor and do they have any ideas as to why this might be happening?
December 3, 2013 at 4:37 am #79884kellyco
ParticipantAfter many, many hours of trawling through the theme code I have found an ‘elseif’ statement that checks if the current page is the front page using the standard wp function ‘is_front_page’.
This is true with Events Calendar Pro deactivated, but false with it activated.
Settings->Reading->Front page displays is set to “Your latest posts” and so ‘is_front_page’ should be true.
Any ideas why activating ECP messes this up – it seems to be a standard wordpress call?
Any suggestions?
Something has changed between ECP 3.1 and ECP 3.2 that breaks this call – at least on my site.
Could you check with the programmers?December 3, 2013 at 3:51 pm #80003Barry
MemberHi kellyco,
I’m not sure why that would be. If you use a theme such as Twenty Twelve, and insert a conditional statement like the following example in a suitable location within the index.php template then it does indeed result in front being added to the output:
<?php if ( is_front_page() ) echo 'front' ?>Perhaps there is a logical issue with the if statement? It’s difficult to assess, but it does seem particular to your theme rather than a general issue where our plugin is incorrectly changing the result of that function.
December 4, 2013 at 7:19 pm #80268kellyco
ParticipantThe is_front_page page call works fine on the ‘twenty thirteen’ theme, but that is a pretty basic theme.
From what I can tell it looks like there is a custom call to WP_Query or get_posts etc in ECP that is not being reset properly before the main page loop is called.
This was not a problem with ECP 3.1, just since upgrading to ECP 3.2 (nothing else changed), so it seems pretty likely that the problem is with something that was changed in ECP 3.2.
I have also tested things with all other plugins deactivated to see if there were any other conflicts, but that does not help.
I have tried finding the right place to insert a ‘wp_reset_query();’ call to reset the query, but cannot find the right location – when I put it before the main page loop it works, but reverses the sort order of the posts (oldest show first rather than most recent at the top).
Do you have some documentation for developers that shows what classes/functions are called when and where by ECP?
What part of ECP might be being called on my home page – the ECP widget is disabled and no events are displayed on the home page – could it be the toolbar menu for ECP? Did that change in ECP3.2?December 5, 2013 at 4:47 pm #80430Barry
MemberThe is_front_page page call works fine on the ‘twenty thirteen’ theme, but that is a pretty basic theme.
Along with Twenty Twelve we view it as a de facto standard for themes as they both enshrine many best practices, which is why we often use them as reference points.
It’s possible an issue was introduced in 3.2, but besides a problem with one of our widgets (and I believe you said you removed the ECP widget you had been using) and considering you aren’t integrating events into the main blog loop I can’t think of any particular reason why this would happen.
We do have a number of query-related changes forthcoming in the next maintenance release though, if you want to wait and see if that yields anything here?
December 6, 2013 at 3:03 am #80489kellyco
ParticipantUnfortunately, this is not really helping.
Testing on Twenty Twelve/Thirteen etc is useful it is but far from definitive in proving that ECP is bug free.
You seem to keep trying to pass the buck and blame the theme I am using – the theme that worked with ECP 3.1 and with every other plugin I have thrown at it for several years and is used by more than 10,000 web sites. In contrast ECP 3 has been riddled with bugs and continues to be so. I thought you would appreciate someone trying to identify the cause of another bug, but you aren’t helping me get to the bottom of this problem. I keep asking for some insight into how ECP is implemented – what functions/procedures are called when it is initiated etc so I can try to find the file or code that is at fault, but you seem to take the stance that your plugin is perfect and it must be something else, just because it works with the most basic theme available. I bought and tested this plugin in anticipation of ECP being available and working many months ago, but instead the filter plugin is still not available and the plugin itself is less stable than ever.
If you look at my home page, what calls would ECP be making that could cause problems with the main loop – i.e. what other calls are being made to WP_Query/get_posts etc?
What steps can I take to get to the bottom of this conflict?
Do you have some debugging notes or tips for people trying to get your plugin to work with their sites/themes/plugins?December 6, 2013 at 6:20 am #80508Barry
MemberI can appreciate your frustration, at the same time it is far from being the case that we claim ECP is perfect or bug free – we know it has bugs and bugs will in all likelihood continue to be detected over the course of its life, as with any piece of software – and we absolutely do appreciate help in identifying possible bugs.
I keep asking for some insight into how ECP is implemented – what functions/procedures are called when it is initiated etc so I can try to find the file or code that is at fault
It’s a complex plugin. If you look at the opening section of code in events-calendar-pro.class.php (the TribeEventsPro class itself) you can essentially follow the breadcrumb trail and see what is being called and when it is slated to execute.
If you look at my home page, what calls would ECP be making that could cause problems with the main loop – i.e. what other calls are being made to WP_Query/get_posts etc?
If you have no event-related widgets in place and have not integrated events into the main blog loop then, even so, a lot will be set up in readiness to respond to certain events (but many will not be actioned). There are a tremendous number of possibilities and really this would require hands on debugging.
If it were me and I was focusing on the Tim Thumb problem I would inspect that first of all – see how it behaves ordinarily and figure out what inputs it takes and what is filterable – then look at the same processes with Events Calendar PRO activated.
Debugging is an advanced topic, however, and I wouldn’t want to offer up any vague guesses that might inadvertently take you off track.
-
AuthorPosts
- The topic ‘3.2 upgrade breaks Infocus theme TimThumb image resizing’ is closed to new replies.
