Large SEO bug in 3.2 – Event title not showing up in the page's title tag

[jebs38]

This reply is private.

[Kevin]

This reply is private.

[Kevin]

Our host supports turning on and off the object cache. That had no effect on this problem.

Adding TRIBE_MODIFY_GLOBAL_TITLE did seem to work on my site. I do hope that an edit to wp-config.php is not the permanent solution here.

[jebs38]

Guys, I forgot to note. That configuration was for the rollback setup.

[siggiboy81]

I added the code to config.php and it did the thing for me. Titles working over again!!

[Oliver]

For me only it works, too! 🙂

[mattsokoloff]

This reply is private.

[Rob]

Thanks for confirming, folks. The fact that this is working for the vast majority of users, honestly, does lead me to believe that those still having problems (Kevin) are dealing with issues that are specific to their install.

To address your concern, Kevin, re:

“I do hope that an edit to wp-config.php is not the permanent solution here.”

This will certainly be the basis of the permanent solution – we’re ultimately looking at making the constant Barry reported in his 11/14 note either ON or OFF by default (probably the opposite of what we’ve got now). But in that case users who are unhappy with the new default behavior will indeed likely still need to use the wp-config change to adjust it as needed.

We’ll look into this based on your report and the system info you provided. But if there’s anyone else who found our fix doesn’t do the trick, please let us know. At this point best I can tell it’s just you Kevin (and while we’re committed to getting you sorted, please understand that it is a bit more challenging to do when it’s an isolated issue). Thanks for your patience so far!

[Kevin]

To be clear, the code did fix my problem as well.

My point about wp-config.php is that plugins should not have to modify that file to function properly. Other plugins don’t modify that file and your plugin didn’t need to modify that file a few weeks ago. Definitely not optimal for maintainability when the plugin starts messing with core files.

I assume that you can load this constant elsewhere, namely in one of the plugin files. That seems to make a lot more sense.

[memeco]

This reply is private.

[Barry]

@memeco: the first thing to do in that case is try (temporarily) running WP without specifying a language and see if the problem is resolved at that point. If it’s not, please do create a new thread as this sounds like it might be subtly different (I’m not actually sure why the locale settings would impact, however).

@Kevin: great that it’s fixed.

To address your point re changing wp-config.php, for many users there is zero need to modify that file. That said, it’s a good location in which to define constants like this one and it’s worth noting that this is neither the only constant definition in The Events Calendar which you might make there, nor is The Events Calendar the only plugin to make use of and test against constants.

I assume that you can load this constant elsewhere, namely in one of the plugin files.

There are indeed other places you could define this constant (assuming you need to define it at all – in your case of course you do, but that’s not true for all users) but I tend to think wp-config.php, which exists for configuration purposes, is the best location for something like this. Alternatively, if you wish to create a plugin to house this definition, or define it within a theme file, then of course you can so long as you do so early enough in the request.

With all that said, the next release should see things effectively switch round so that, in your case, you can remove that definition from wp-config.php (but leaving it in place is fine, too). I hope that clarifies things and since I think (with the exception of your good self, memeco, but please do open a new thread) everyone has a workaround and we have a substantive change coming probably in the next maintenance release I will go ahead and close this thread.

Thanks!

[Author]

Posts