Navigate Month-to-Month from Events Page

[Anonymous]

I cannot seem to get the main Events calendar (http://goodhopenaz.org/events) to navigate to the previous or upcoming month using the << and >> links. It seems as though all links point to domain/events/#. Is there a quick/easy way to allow users to click the >> to see what is scheduled up ahead?

Thanks!

[Franky]

Ca you try if this fixes it? Replace eme_calendar.php by this one:

http://plugins.trac.wordpress.org/browser/events-manager-extended/trunk/eme_calendar.php?format=txt

It probably happens because you use the templating functions, and not the shortcodes. Is this possible?

[Anonymous]

I’ll give that a shot. I can’t really say that I used “template functions” or not. I didn’t use anything. I just selected Events as the page for EME and set my browser to go there.

I also noticed that when I created an event for which we required RSVP, no form nor any details that were entered displayed on the page.

— Renamed the old eme_calendar.php file to eme_calendar_OLD.php and uploaded the new one you linked me to in its place. Cleared my browser cache and revisited the Calendar: http://goodhopenaz.org/events

The << and >> links are still non-functional.

[Franky]

For forms and the lot: you need to configure the format for the event list and for the single event to your liking. See http://www.e-dynamics.be/wordpress/#formatting-events

For your problem concerning the arrows: check the EME setting “Events page” and see that it points to a valid page. Normally EME creates this page and you should not use it, touch it, delete it in any way.

See the remarks for this field and also the faq “How does Events Manager Extended work” on http://www.e-dynamics.be/wordpress/

[Anonymous]

I found the form information and was editing that as you replied. I have some tweaking to do there, but it’s coming along.

With regards to the link arrows, it is pointing at a valid page. I tried to convey that in my last message, but I didn’t do the best job. When I said, ” I just selected Events as the page for EME and set my browser to go there.” I was trying to say the only configuration I had made in the settings panel was selecting the proper page for EME. I have done nothing else to the page.

[Franky]

Well … I can see that the javascript needed is not being loaded (I don’t see it in the footer of your page anyway). So maybe you can give me some admin access so I can see things for myself? My mail: liedekef [at] telenet.be

[Anonymous]

Thank you… I’ll set you up with a temporary Editor account. Will that give you sufficient privileges?

If yes, your username is ’eme’ and your password has been emailed to you.

[Franky]

Nope, editor won’t cut it, I need admin to check the settings.

But I think it’s related to your theme. Your theme needs to call get_footer() and probably that doesn’t happen anywhere. See the twentyten theme for this.

[Anonymous]

You have been promoted to admin…

If it is as you suspect, would I be dead in the water short of starting over or doing serious rework to the theme or is that something that could be handled easily with a very simple child theme?

The home.php includes the following call: <?php get_footer(); ?>

It is also located in the basic page template… “page.php” I do not yet know if it is anywhere else, but I did note that it isn’t included in the Theme Functions page.

[Franky]

It is your theme: the function get_footer calls footer.php from your theme, which in turn *NEEDS* to call wp_footer() …

So smack those you bought it from, make a donation to me 😉 and add this in your theme’s footer.php just before the closing </body> tag (taken from twentyten theme):

<?php

/* Always have wp_footer() just before the closing </body>

* tag of your theme, or you will break many plugins, which

* generally use this hook to reference JavaScript files.

*/



wp_footer();

?>

Now it might be that this breaks other jquery stuff if your theme includes that on its own (the wp_footer() call includes the jquery frm wp and other footer-javascripts from plugins), so testing is advised …

[Anonymous]

Thanks. I WILL remember you when I have some cash… got laid off just before the Thanksgiving Holiday which made Christmas pretty tight. Doing this as a volunteer project for the church.

There’s no good way to make tweaks such as this that still work if theme updates come along is there? Kinda like a php version of the CSS child themes?

[Franky]

Laid off just before Thanksgiving? That’s not good … I’m glad I could help you then 🙂

Anyway, I don’t exactly understand your question here, but if your theme doesn’t call wp_footer(), you need to include it … but I see on your site it works now, nice!

[Anonymous]

Yes, I appreciate your help. I really do.

Not only does it work, it doesn’t seem to have messed anything else up… at least nothing OBVIOUS. 😉

—

Let me think about how to re-word my question.

I’m sure you’re familiar with WordPress “child” themes. You know you add an “extra” CSS file to your theme with your tweaks (whatever they may be), rather than editing any of the theme’s included CSS files. That way, when the theme author releases updates to his/her theme you can install the updates/fixes/etc. but his updates don’t overwrite the modifications that you made because yours are still housed safely within your “child” CSS file.

Is there anything like that I could do with the PHP code you provided? Maybe place it into a file ‘wp_footer_call.php’ (for example) and still keep the benefits it provides. So that if/when our boldy theme gets updated I don’t have to return to footer.php and add this code again?

Rest assured, whatever your answer is, I will be contacting site5 (who authored boldy) and inquiring as to why they left this code out of their footer.php in the first place.

[Franky]

Hmmm … I see, but I’m not much into theming though 🙂

But since get_footer() includes the file footer.php, I’m guessing that one needs to call wp_footer(), and according to what I know, there’s no way around it … they might just have forgotten it.

[Anonymous]

I will share a couple thoughts about themes, the first being about themes in general, and the second specific to development of a new WordPress theme at this time.

I have customized and maintained a wide variety of theme-able software products for myself and for customers over many years. I have learned the “hard way” from that experience that unless there is a very strong reason to do otherwise it pays to not deviate very far from sample themes provided by core product developers. It generally isn’t difficult to create good custom themes that are vastly different. The problems come with the time, effort and/or expense of keeping them compatible with new core product version releases. Theme-able software product users often obtain themes from third parties that were designed to be used with older versions of the core product, that haven’t been updated, and that rarely are updated to take advantage of important security fixes and enable new features. Users regularly update the core product and assume they have the “latest and greatest,” but that often is not true.

The new WordPress 3.1 that is nearly ready for release provides a good example. WP 3.1 has a variety of valuable new capabilities that most WordPress users won’t benefit from, because they will use it with old themes that don’t support the new things. Using a theme derived from and very similar to the WP 3.0.x TwentyTen theme won’t automatically enable the new capabilities, but it will make incorporation of the required changes considerably easier. WP 3.1 comes with a new TwentyTen Version 1.2 theme that has new code needed to take full advantage 3.1. Someone using a theme that is very similar to the previous TwentyTen theme can use a product like WinMerge to compare changes in each theme file and then incorporate them into their custom theme, but users of other themes will have a much more difficult problem. So difficult, that many, probably even most, will continue using old themes and then wonder why new 3.1 features don’t work. This is a perfect time to develop a new WordPress theme, because of the pending WP 3.1 release, but anyone doing that should pattern their new theme closely after TwentyTen 1.2 to minimize future “pain and suffering.”

This is of course an EME support forum and not a WP support forum, so the comments above may seem inappropriate here. However, WP plugins are designed to be used with and are tested against current versions of the core product. The use of themes designed for old WP versions is a common cause of plugin malfunctions, so it isn’t inappropriate to stress the importance of using themes designed for the current product.

[Anonymous]

I see what you’re saying on one hand admintiger, but good luck becoming or staying the number one (or number two for that matter) blogging platform with a slogan like, “We’re completely themeable… but we don’t recommend it!”

Any time you add or change any “defaults” of any product you are changing the way it was planned, and it isn’t just with theming. Sometimes two plugins are incompatible with one another. In theory, WordPress is “designed” to be modular and themed, but theory doesn’t always equate to law. Anyone who wants to change their brand packaging (theming) does so knowing (or at least hopefully, knowing) that their is a cost/benefit analysis that needs to take place. The same can be said of anyone who needs extra functionality to their blog/cms and adds it with a third-party plugin.

In general, I think most people know that if you get four different “things” (themes, plugins, platform software, etc.) from four different people, you can’t have a realistic expectation that they are all going to play nicely together right “out of the box.” And the reason for that is simple… you didn’t get them out of the SAME box.

All of that aside, WordPress boasts that it can be easily themed and easily extended… that is one of (not the only) its major selling points. If you start waving big flags telling people otherwise you’re shooting your marketing platform in the foot.

My 2 cents.

[Franky]

Well, theming, modules; it’s all the same in the end: if you don’t use the new functionality, you don’t use it, but then you can’t expect everything else to go your way. WordPress has a theming functionality, but it isn’t the best in the world 🙂

Or even more simple: old themes work with old plugins on a newer wordpress, but a new plugin taking advantage of new functionality won’t necessarily work with old themes. I would say “like the wp_footer thing”, but apparently this is a very old function that every theme should use:

http://codex.wordpress.org/Function_Reference/wp_footer and

http://codex.wordpress.org/Theme_Review#Template_Tags_and_Hooks

[Anonymous]

Maybe I am reading you wrong Franky, but are you saying that old themes and old plugins that worked on previous versions of WordPress (2.7 for example) continue to work when WordPress hits 2.8, 2.9, 3.0+?

That hasn’t always been my experience, and even browsing the WordPress.org extensions they have that nifty little “compatible up to” identifier.

[Anonymous]

Goodhope, our differing points of view fundamentally relate to different judgments about the cost vs. value of someone having exactly what they want. There is no doubt that a big reason for the success of WordPress is the ease in which it can be customized. However, there is more cost associated with that than most users initially appreciate. If someone is willing to spend the time or money that will be required over time to keep a highly customized site secure and otherwise running correctly or if they don’t care whether their site remains secure and running correctly they are welcome to do whatever they want. However, experienced developers who fail to explain the typical costs of maintaining highly-customized sites over time are not acting in the best interests of their customers and beginners who highly customize their own sites seldom understand the long-term consequences. I am not against customization where the value exceeds the cost. I am only warning that there is cost associated with seductively easy customizations. Someone with a limited money or time budget for website maintenance is best advised to customize sparingly even though products like WordPress make it easy to change almost anything.

[Franky]

Goodhope: no, you’re not reading me wrong: most of the time the modules work, or worse: most of the time people keep using old modules that are no longer validated for their newer version of WP. I had that problem several times before on this forum where people log a bug when in fact an outdated plugin was at the source (while that plugin seems to work fine on its own). WordPress should in fact prevent these modules from being activated at all, in order to prevent these things …

And admintiger (besides the long text ;-)) : indeed, many companies fall into the trap of customizing things and then get stuck with older software that nobody dares to touch anymore (customized browser for intranter, customized thunderbird for mail, etc …). If you have to make modifications: document them and keep them simple and clear (and hope for the best if an update comes along).

[Author]

Posts