Event Calendar (Standalone) Causes 404 on Sermon Pages « Support Forum | Kriesi.at - Wordpress Themes and HTML Templates

Kriesi.at - Wordpress Themes and HTML Templates

Support Forum » Incarnation

resolved

Event Calendar (Standalone) Causes 404 on Sermon Pages

54 posts from 6 voices

Started 5 months ago by mnibreanne
Latest reply from Nick
This topic is resolved

Tags:

mnibreanne
Member

The short version:

When using The Events Calendar PRO (having installed it, as well as the standalone version of the TEC, and disabling the built-in version), there exists an issue which causes some of the pretty permalinks for the sermon content type to not work. I believe I have tested every possible configuration to demonstrate that the issue is between the latest version of TEC and the Incarnation theme. Details below :-)

The long version:

The error can be seen on both single sermon and sermon category pages, though the full sermon archive works fine.

Example problem links giving 404 errors:
http://wccac.net/external/sermon-overview/abcd/
http://wccac.net/external/sermon_categories/english/

Background:
I have installed the Pro version of the Event Calendar, which required me to also disable the built in event calendar plugin so that I could install the current version of the base plugin. I commented out the code as described in http://www.kriesi.at/support/topic/need-help-on-pro-version-of-calendar#post-88156

Test results:
The problem does NOT exist when using the built-in event calendar plugin.
The problem does NOT exist when the permalink settings are set to default (this suggests to me that there is a rewrite conflict perhaps?)

The problem DOES exist when all other plugins are disabled.
The problem DOES exist when TEC (standalone) is installed without TEC-PRO.
The problem DOES exist after flushing the rewrite cache.
The problem DOES exist after re-saving the permalinks settings.

The .htaccess file is writeable and has not been altered.

Thoughts?

Posted 5 months ago #
mnibreanne
Member

Hey Nick - this does not appear to have resolved the problem:

http://wccac.net/external/sermon-overview/abcd/
and
http://wccac.net/external/sermon_categories/cantonese/

still give 404 errors (I have cleared the browser cache - not using WP caching right now - disabled all plugins, regenerated permalinks, no change).

It also introduces a new problem, in that any sermon category archive page which does not have any sermons redirects to an event page, rather than giving the category page and the note that there were no posts in that category.

e.g. With the fix, http://wccac.net/external/sermon_categories/english/ redirects to http://wccac.net/external/event/english-sunday-school/

Of note, I've disabled the PRO version of the addon, so as to ensure that any fixes we test are being tested only on the free version of TEC.

Posted 5 months ago #
Devin
Moderator

Hi mnibreanne,

I'm not intimately familiar with The Events Calendar at this point so while Nick is digging into it I'm also tagging Kriesi and the head of support to see if we can get another pair of eyes and of course Kriesi's expertise on it.

Regards,

Devin

Posted 5 months ago #
Dude
Dude

Tbh I'm not even sure if the events calendar plugin is fully compatible with WPML yet. Several posts (eg http://tri.be/support/forums/topic/wpml-and-the-events-calendar/ ) indicate that there still some compatibility issues. You can try to switch to another theme like TwentyTwelve and check if this solves the sermon category issue. If yes this can be a theme specific issue - otherwise I'd contact the event calendar dev team and ask them to look into the WPML compatibility issue.

Posted 5 months ago #
mnibreanne
Member

It isn't WPML, because it occurs when TEC is the only active plugin. The only time the incompatibility arises is when I am using the latest version of TEC and this theme. I can't try testing with another theme, because the sermon type is defined by this theme.

Posted 5 months ago #
mnibreanne
Member

Okay more info.

It seems to have something to do with the slugs on the events and sermons.

For example, I had created a category of sermons called "English" and a category of events called "English".

I initially noticed the issue in that I went to rename the slugs for the events (so as to be unique from the sermons') and found that the sermon slugs had changed as well.

What's interesting is that I had created my categories and slugs using the built-in event calendar plugin and it let me use the same slug for both sermon and event categories. It no longer does so, which is fine, as the new plugin enforces uniqueness in the slugs.

Now, one would think I could resolve this by deleting all of my categories in both events and sermons, and then recreating them with unique slugs. Alas, no such luck. Same issues, even after deleting all the categories, giving unique slugs, etc.

Every time I made a chance, I rewrote the permalinks, and even did a flush of the rewrite rules.

----

Finally, to further complicate things, it looks like it could be a case of corrupt data being cached somewhere as a result of the problem I had with the slugs being non-unique. On a different site and server, I tried doing a clean install of WP3.5 plus the theme, plus a standalone version of TEC, plus even WPML (to rule it out) and cannot reproduce the issue.

----

Will keep investigating... and hoping I don't have to re-set-up all of my work to-date. If anyone has any ideas for caches that may be causing problems, or other taxonomy-related ideas... love to hear them.

Posted 5 months ago #
mnibreanne
Member

More testing results:

On my test (clean) install, I copied over the wp_options table from my live (problem) install. The problem that I had previously only seen on live was now happening on test.

I then cleared out the avia_incarnation_options record from wp_options on test, and then did a save on the theme options from the admin panel in order to regenerate the theme options record with the default values. The problem that I had seen on live no longer occurred on test - therefore, the problem was corruption in the theme settings having been saved to wp_options.

But here's where it gets weird.

On a hunch, I went and just did a "save" on the theme settings page on my live set up - perhaps by re-saving, I would overwrite the corruption.

This caused me to be able to see a single sermon OR single sermon category archive... once. If I tried to reload the page, or otherwise view a sermon archive or single sermon page, it would 404 on me. If I go back and save the theme settings, it'll again work... once. But not again, until I refresh the theme settings.

But then... I nuked the theme options from wp_options on live, reinstantiated them, etc. (same as I'd done on test) and the problem still is fixed for one pageview after saving the theme... and then broken thereafter.

Posted 5 months ago #
mnibreanne
Member

Reuploaded the theme, to see if that would make a difference. Seemed to... sermon category archives and individual pages started working!

...

Except I had 404s on the rest of the pages.

Put flush_rewrite_rules( false ); in functions.php and the 404s on the rest of my site go away... but come back on the sermon category archives and individual pages.

[edit] I managed to get it momentarily working by changing the permalink structure about 5 times in a row, but it's now back to the above (404 on all non-sermon/event page) behaviour.

Posted 5 months ago #
mnibreanne
Member

Like I said when Dude suggested it, I did clean uninstall of WPML and the issue didn't seem to go away at all (though I admit that I've done so many iterations of testing, I can't recall the exact behaviour I saw upon doing so, and given that I've got WPML actually working on my site, I'm loathe to do an uninstall of it while they're trying to debug it). I only reverted after testing that. /shrug

I've also reviewed the diff between the two versions and note that the following rewrite is present in wp_options prior to the page refresh (when everything works), and missing thereafter (when things no longer work):

< <table name="wpx_options">
< <column name="option_id">60037</column>
< <column name="option_name">avia_rewrite_flush</column>
< <column name="option_value">1</column>
< <column name="autoload">yes</column>
< </table>

The block for the option_value (which is where the bulk of the volume is coming from) is also flagging on the diff, and I haven't dug into that in its entirety... but it would seem to me that the above might be a place to start, given that we're talking specifically about a problem with rewrite_rules, no?

Posted 5 months ago #
mnibreanne
Member

Okay, I just finished analyzing the diffs in their entirety, including the big block of gobbldigook in the option_value column. What follows is a list of all changes between the two versions:

in wpx_options, option_id 60038 (rewrite_rules) is removed and re-inserted as 60042 (rewrite_rules). I have confirmed there are no changes to the option_value block (which is the part that is several megs large).

in wpx_options, option_id 60037 (avia_rewrite_flush) is removed and NOT re-inserted.

Thus, the only actual difference is the absence of the avia_rewrite_flush in the options table.

It is set in function-set-avia-ajax.php:

//flush rewrite rules for custom post types update_option('avia_rewrite_flush', 1);

And removed in function-set-avia-backend.php:

function avia_flush_rewrites() { if(get_option('avia_rewrite_flush')) { global $wp_rewrite; $wp_rewrite->flush_rules(); delete_option('avia_rewrite_flush'); } }

Where does that leave us? I have no idea ;-)

Well, I tried manually calling avia_rewrite_flush in my functions.php file and can confirm that the following occurred:

I saved the theme options
Immediately went to a sermon archive page
Sermon archive page gave a 404 (rather than working once, and only subsequently giving the 404)

So, it would appear as though there may be something about the way that the avia flush is happening that is causing problems? Maybe? If I'm lucky?

Posted 5 months ago #
mnibreanne
Member

Hey Nick,

Yeah, I tried commenting that out (the conditional, the delete, and other variations) yesterday - worked at it for several hours - no dice.

WPML has confirmed that the 404 issues are not as a result of their plugin; see link: http://wpml.org/forums/topic/yet-another-404-error/#post-97562

It is worth remembering as well that the issue only occurs when the standalone events calendar is installed, and does not occur with the built in one. So focusing on WPML may have been a red herring all along, as TEC+Incarnation is where the funky interaction is happening...

I also did a full diff of The Events Calendar code which is currently available (2.0.10) and the one that comes preinstalled with the theme. There were changes made in their rewrites as part of their 3.5 update, which is what made me curious if the theme had also had its similar updates made. That said, I couldn't see anything in the diff'd code (of TEC) that made it obvious to me as to where the conflict would have been introduced.

I'm going to dig further into rewrite rules... learning more about WP than I ever thought possible...

[edit to add: I should also say that, even if it were to work, I'm not really satisfied with the of having rewrites fire on every page load, as that's a highly unnecessary server cost which we should be able to remedy with a root-cause fix]

Posted 5 months ago #
mnibreanne
Member

The good news: I have managed to get the behaviour of the site to remain the same whether I manually flush the rewrite rules (using both/either flush_rewrite_rules and avia_flush_rewrites()) or not. This means that the sermon archives are now working at all times.

This was done by adding "has_archive" to the sermon_categories args in register-sermons.php

register_taxonomy("sermon_categories", array("sermon"), array( "hierarchical" => true, "label" => "Sermon Categories", "singular_label" => "Sermon Categories", "rewrite" => true, "has_archive" => true, "query_var" => true ));
The bad news: I still get 404s on every other page of the site, and whereas previously flushing the rewrite rules in functions.php would cause the pages to work (but not the sermons), now the flush does not resolve the problem.

Note - the 404s do not occur when WPML is disabled (finally!) so I will go back to WPML with this new finding. It does appear, however, that the lack of has_archive was at least part of the problem.

Posted 5 months ago #
Nick
Moderator

Hi,

Nice find! However having an archive pages for sermon categories (not the sermons themselves!) was not a feature of the theme, so that's my guess for its absence. I saw in the current WPML - one of the options with a warning that translating cpt slugs is experimental. Are you using that feature?

Thanks,

Nick

Posted 5 months ago #
mnibreanne
Member

Heh - as soon as I added has_archive to the sermon registration, the built-in event calendar stopped working, too.

(But again, at least the problem is only happening when WPML is enabled - and only on default language pages, secondary/Chinese pages are fine).

The latest status is now exactly the same as zenbatgara described here: (http://www.kriesi.at/support/topic/with-wpml-i-get-404-not-found-for-pages-in-default-language) ... which appears to be a bug between WPML and the theme, without any other plugins being installed or enabled.

(Oh, and for kicks, I tried the first suggestion solution again - changing to is_tax as the only conditional in that one statement ... no dice)

So bizarre...

Posted 5 months ago #
Nick
Moderator

You are sharp, I was thinking of is_tax after reading your 2nd sentence.

If you don't mind can I take a look? Please set me up an account usjahm (aaaattt) gmail (doooot) com.

Thanks,

Nick

Posted 5 months ago #
mnibreanne
Member

[Yay simulpost!]

Yeah - we're using the archive because we have 3 different language communities, so we're using categories to determine what language the posted sermon is in - while still making all sermons available regardless of what language you're viewing the site in. So, we get a listing of all English sermons by looking at the English archive, even if we're browsing the site in Cantonese.

CPT - I've tried both with 'translate' and 'do nothing' set. No change.

Will set you up the account right away. Just be aware that the WPML guys also have a set of credentials, so they may be in there too at times (if you see strange stuff happening).

Posted 5 months ago #
zenbatgara
Member

Hello,

Last week I posted about my problem with WPML giving 4040 errors on pages in the default language:
http://www.kriesi.at/support/topic/with-wpml-i-get-404-not-found-for-pages-in-default-language#post-91437

Today I've just checked if there was any answer only to find that an administrator called Dude has merged my request with this one and closed my topic, despite the fact that my problem has nothing to do with The Events Calendar (I don't have even installed it yet) nor with sermons, just a fresh install of WP, the theme (Incarnation) and WPML, which don't seem to work together.

I want an answer to why Incarnation is not working with WPML and so far all I have is... Tell me what.

Is there any known solution solution for MY website's problem, will there be a fix soon or do I have to look for some other theme that does work with WPML?

Thanks for your help
Jabi

Posted 4 months ago #
zenbatgara
Member

Hi Nick,

Permalinks are set to be "Post name", that is, /%postname%/

I've just sent an email to you with the login details.

Thanks,
Jabi

Posted 4 months ago #
Nick
Moderator

Hi,

I am still examining the issues for both of you. Sorry about the delay.

Thanks,

Nick

Posted 4 months ago #
mnibreanne
Member

Hey!

Thanks Nick. WPML is still also investigating. Maybe it's a race to who can find the problem(s) first? :-)

Regards,
Peter

Posted 4 months ago #
Nick
Moderator

@mnibreanne Hi, Yes, I haven't changed/added/removed any plugin or setting since that may invalidate any data they are gathering. Just needed to see settings and plugins. We will get there , no worries!

Thanks,

Nick

Posted 4 months ago #
Nick
Moderator

Hi,

OK! I good news and bad news. This concerns both of you @mnibreanne and @zenbatgara as you both have WPML languages as 'Different languages in directories' option which creates the following format for translations: you-domain/en/ and your-domain.com/es/ as an example.

The bad news is you must follow the rules below and make the change in order to get back on track. There are two rules below and both of you are breaking them. In order to be able to use 'Different languages in directories' structure: It doesn't matter which of the two rule below you decide to abide by, but you can not continue breaking the other one :)

Rule 1) The URL of your home page *must be* your-domain.com - and can not be in a sub-directory: your-domain.com/some-sub-directory/

or

Rules 2) The permalink structure in Admin > Setting > Permalinks *must be* default. No custom permalink structure allowed.

You can break only 1 of these rules, you can not break both. Right now you both have (a) custom permalinks and (b) you both have your website's homepage in a sub-directory, So in order for WPML to work with languages in a sub-directory, you must either (1) change the permalinks to default; or (2) Move your site so that the home page url is the same as the url of your domain name..

The good news is that I can get some sleep a bit now while you two take care of this issue please. The WPML rules are below::

Ref: http://wpml.org/documentation/getting-started-guide/language-setup/cannot-activate-language-directories/

The one below says that you 'must NOT use the default permalink structure', while the one above says to 'use the default permalink structure' ,,, So unless the rule below is incomplete, unfortunately you only have 1 choice for this to work with sub-directories, to please move the homepage out of the sub-directory to the root of your domain name.

Ref: http://wpml.org/documentation/getting-started-guide/language-setup/#visitor_language

Thank you,

Nick

Posted 4 months ago #
shelteredinsound
Member

I don't want to hijack this thread but have been following along with this as I'm having the same issue. My site is not in a subdirectory. Same issue with 404 errors on "pages" using WPML and permalinks. Theme specific. I loaded another theme and it runs as it should. Something in Replete seems to trip this up. Solution provided does not solve issue. I guess we need another confirmation from the originators of the thread but I'm still without a solution.

Posted 4 months ago #
mnibreanne
Member

Ugh, that sucks. Thanks, Nick. The thought of it being in a subdirectory messing things up had crossed my mind, but I'd eliminated it after reading some other support posts on WPML's site (particularly this one: http://wpml.org/forums/topic/wp-in-sub-directory-using-wpml/ - and the fact that it works on http://www.icanlocalize.com/site/) - hadn't seen that particular link. I guess I'll have to follow-up with WPML for a real solution (even if it's just futzing with the .htaccess), since neither of those "rules" are going to work for this client.

Posted 4 months ago #
mnibreanne
Member

So! Here's a fun one.

I noticed that there is a new version of WPML out today, and updated to it. In the patch notes:

WPML 2.6.4 fixes the language switcher for product pages on some e-commerce sites, archive page slug translation, default Chinese locale, Finnish locale for WordPress core translation, and some robustness improvements for our language configuration files.

(emphasis mine)

Given that this was one of the originating issues, I went and re-added the flush_rewrite_rules(false) to the theme's functions.php file.

And... guess what.

It works.

All of it.

No 404s on default language, no 404s on sermon archives, etc.

(Other than the pesky presence of the flush_rewrite_rules, that is.)

[edit to add]
Please don't shoot me :P

Everything works... so long as I don't install the standalone version of The Events Calendar. If I do, then I get the same rewrite problems as before, where the sermon categories and individual posts don't work.

This is SO convoluted, I'm about ready to say just screw using The Events Calendar PRO... just eat the cost and leave it be. At this point, I can't tell where WPML, TEC and the theme begin and end... the problem could be in any of them, or in the interaction of any of them :-/

Posted 4 months ago #
shelteredinsound
Member

I downloaded the new WPML plugin release and added that "flush rewrite " fix and can confirm it fixed the issue with permalinks and the 404 error on pages on my site as well. Nice find mnibreanne! I'm still getting 404s with the replete theme and the woo commerce plugin but one thing at a time:-)

Posted 4 months ago #
mnibreanne
Member

For the hell of it, I did a fresh install of WordPress, WPML and Incarnation - to be able to reduce potential trouble spots.

Steps taken to reproduce:

WordPress+WPML+TwentyTwelve – works okay.
WordPress+WPML+Incarnation – 404s occur (except when rewrite rules are flushed in functions.php, which works around the issue).
Revert back to TwentyTwelve – 404s occur until permalinks are cleared.

So it's not an issue with the subdirectory install, since everything works fine using the default WP theme. It's something to do with the permalink generation that Incarnation is doing.

Posted 4 months ago #
shelteredinsound
Member

Something not happy within the Kriesi frameworks. I've tried this with various themes and on different servers. WPML permalinks is solved with this back and forth but issues remain if you need WooCommerce as well. At least in my case.

Posted 4 months ago #
Nick
Moderator

Hi,

Please hang in there. Kriesi has been working on this along with other tweaks I am sure you will all appreciate, all as part of the next set of framework updates which will be out any day now.

@mnibreanne Have you looked at file /incarnation/config-events-calendar/the-events-calendar/vendor/wp-route/ ... in file WP_Router.class.php ..

the function on lines 151-158 and 291-294. are they present also in the event calendar plugin itself?

Thanks,

Nick

Posted 4 months ago #
mnibreanne
Member

Can't recall if I looked at that bit of code directly or not; I'll check it when I'm back "in the office" (so to speak) tomorrow.

The folks from WPML have suggested that you may want to work directly with them to resolve the apparent compatibility problem. See the latest post in this thread:

http://wpml.org/forums/topic/yet-another-404-error/#post-100362

Posted 4 months ago #

RSS feed for this topic

Topic Closed

This topic has been closed to new replies.

© Copyright Kriesi.at – Wordpress Themes and HTML Templates

top