Forum Replies Created
-
Posts
-
Have you tried increasing the amount of memory available to PHP (do talk with your host if you are unsure as to how this should be done)?
It depends on the update: a major update may indeed introduce a number of breaking changes with regards to custom style rules (and customizations generally), however minor updates should not cause any considerable disruption.
For example, just as styles targeting 2.0.10 would have been extant for 2.0.11, a rule targeting the layouts generated by Events Calendar PRO 3.0.4 would work pretty seamlessly with 3.0.5 and I’d expect them to still be valid when 3.1 arrives.
Further ahead is harder to predict, but (and this is nothing more than speculation) if we reach a 3.5 release or move to a 4.0 release you might again expect to have to re-tool any customizations if you want to use the latest codebase.
I hope that answers your questions 🙂
Hi Noxaen,
Let me try to answer these points in turn.
Now the recurring events have been separated into multiple single events instead of data in just one post. Is this correct?
Not quite. Although it may seem superficially as if there are many separate events/posts there is actually only one and the recurring instances are established using post meta data. Structurally there isn’t a particularly large difference between 2.0.11 and 3.0.3 in this regard.
As for wanting to retain the earlier design, I have no choice but to redo am I right?
If you want it to look exactly as did the earlier version then you’d certainly have to make a number of changes.
If this is the case and I choose not to update it, will ModernTribe still help me fix the ‘date reset issue’ I initially have?
It’s unlikely in the extreme that we will make any further changes to the 2.x codebase, so even if this did happen to be a bug in our code the fix (assuming a fix is needed in our newer releases) would be applied to the current 3.x stream.
All we can really do here is suggest you run through the regular troubleshooting steps (deactivate all other plugins and switch to a default, unmodified theme) as this isn’t something that we have seen on a “stock” installation of our plugins, even with those earlier versions, and certainly looks like a conflict.
Excellent – sounds like you are all set and so I will go ahead and close this thread. If there’s anything else please do feel free to create new threads as needed 🙂
Right, but the .content-sidebar body class is present (and that’s probably the result of your snippet) – you’d really need to dig in to Genesis here to figure the rest out and, I’m afraid, that’s not something we can help too much with.
Hi noxaen,
Generally speaking if you have two distinct sites and you wish to receive automated updates and support for both then it would be advisable to have two license keys (or a business license). If one of them is a dev site however then there is no particular need to do this – the software should function just fine without a license key.
Thanks!
I’ll go ahead and close this thread as there’s not a great deal more we can do at this point in time, of course if you need further help on anything else please feel free to create a new thread or threads as required 🙂
Hi Steph, apologies for not being clearer: the theme’s functions.php file, or else the functions.php in a child theme (if appropriate in your case), are acceptable homes for this code.
what means redeclare?
It means you’ve added the same function (a piece of code) twice. Generally speaking you should add it only once.
Does that help?
We’ll happily provide an example of some CSS you can drop in – but can you first point me to a relevant page (I looked at the URL you provided, but could not identify your main events page) and give us an example of how you want to colourize events?
Thanks!
https://tri.be/support/documentation/events-calendar-themers-guide/Definitely, just let us know. It certainly worked for me insofar the code ran on the appropriate filter and returned ‘content-sidebar’ as expected – however it’s entirely possible that was overwritten in turn later in the request or of course just wasn’t sufficient to achieve the end goal.
Ah, I see! Apologies for the misunderstanding.
Well these are basically fields that allow you to add text (HTML, including images etc) before and after the display of event pages. It’s basically up to you what you might put in there – some people might like to add a phone number for a ticket hotline, others a disclaimer, others still some extra markup to help event pages gel nicely with their theme – however it is probably not an ideal location for custom CSS and we’d recommend the steps described in the Themer’s Guide for that:
https://tri.be/support/documentation/events-calendar-themers-guide/
Some people have had a few issues, though as far as I’m aware there is no reason that Genesis cannot run with 3.0.x with a few tweaks in place and there’s plenty of anecdotal evidence of just that across the forum. If you need to stay on 2.0.11, though, then we’ll help if we can (though this help will be naturally more limited since there will for instance be no more bug fixes for the old code-base, etc).
To the issue at hand, it looks to me as if the add event button which you put in place unfortunately consists of badly formed HTML (the anchor element is opened but not closed):
<div class="add-event-button">
<a href="http://sandboxing.capemyers.com/events/community/add">Add Your Event</div>
I’m not sure why that has happened but it’s quite possible that this is confusing browsers and consequently changing the appearance of the list/grid view links/buttons.
Could you revise your custom button code and see if that helps?
