[Steven W]

OK…this is embarrassing…too little coffee…my question concerns a different plugin completely. Sorry for wasting your time…

[Steven W]

This reply is private.

[Steven W]

This reply is private.

[Steven W]

I should have noted that on my (working) Prod platform, the combination of WP Migrate DB 0.9.2 and TEC 4.5.2.1, TEC Category Colors 4.6.6, and TEC Pro 4.4.8 is working as expected. The issue occurred when I updated from TEC 4.5.2.1 to TEC 4.5.6 and from TEC Pro 4.4.8 to TEC Pro 4.4.12.

• This reply was modified 6 years, 10 months ago by Steven W.

[Steven W]

I haven’t updated our theme in months–mainly because the last major update to it (HB Themes Highend) required a convoluted uninstall/reinstall outside the normal update process and I just haven’t had the time to mess with it. But whatever the issue, the custom css fixed it and I’m happy. Again, thanks for the assistance.

[Steven W]

Thanks, Brook. That did the trick–although I’m not clear as to why this would need to be custom css rather than part of the TEC css… I’m pretty sure this issue only cropped up recently–after one of the updates. That is, it was working fine with our theme previously. In any event, that takes care of it.

[Steven W]

I have indeed upgraded to 4.4 and after following your instructions, the problem persisted…

I tried changing permalinks to “Plain”, which resulted in a 404-Not Found error (which I think I understand, given the way TEC renders the page, and I don’t want Plain anyway). Then I changed permalinks to “Numeric”, which rendered the page, but didn’t fix the problem I’m reporting here. I purged both local and server-side caches between each step, by the way.

Will await further instructions from you.

[Steven W]

Once again, you’ve come through with a thoughtful, honest answer to an issue — and I appreciate it. I kind of understand your explanation, and accept it (though, as you correctly guess, I’d rather not have to 😉 )

Yes, I’d appreciate it if you’d bring it up in your meeting — so that at least this particular use-case gets some visibility.

Curiously, I pinged SiteGround on the issue as well. They allow their employees to log in to a client’s site to troubleshoot, which this fellow did. He couldn’t reproduce the problem… I’m not sure what to make of that, but again, your explanation leaves me thinking that the issue “makes sense” to you from a TEC coding perspective and isn’t just my imagination. As always, I’ll appreciate any progress on this you all can muster.

It’s still one of the best pieces of software I’ve run across in terms of quality of coding, and your support is second to none in my book.

Thanks!

[Steven W]

OK, here’s what I’ve discovered… We use SiteGround as our hosting provider (been extremely happy with them, by the way). They have a tool called SuperCacher that comes with the service level we subscribe to. It has three levels of caching (I’m not real conversant on all this, so I hope it makes sense to you). Level 1 is a static cache, Level 2 is a dynamic cache, and Level 3 is called “Memcached”. I’ve narrowed it down to some kind of problem with Memcached… If I turn off Memcached, the Week view works — or at least it has worked the five or six times I’ve tested that scenario. If I then turn on Memcached, the Week view still works the first time, most of the time, but if I go somewhere else in the website and then return to the Calendar and select Week view, I get the File Not Found error.

I have a vague understanding of caches, and assume that that first db call (to display the Week view) is cached, but cannot understand why the second call cannot be fetched properly, resulting in the File Not Found error. I understand that you don’t/can’t support someone else’s software, but am compelled to ask if there is any way the TEC code could be a “partner” in this problem. Because I don’t fully understand caching or how it works at a technical level, I’m flying blind here. I’d like to take advantage of the performance improvement Memcached supposedly provides, but obviously can’t do that if it simply results in the error. SiteGround has been very supportive in the past, but I’m fairly sure that without access to the TEC code, this isn’t something they can fix either. Or is it?

Any help or guidance will be appreciated.

[Steven W]

Thanks, George. As this is on our semi-production site (currently in maintenance mode before we launch), there are other folks adding content, so I can’t try this right now — but I’ll try this evening when everyone is off and let you know what the results are.

[Steven W]

Marking this one resolved.

[Steven W]

OK, that did the trick! After a couple of little styling tweaks, it looks almost exactly as it did before the initial issue appeared. Thanks to both of you for your persistence and your patience with me in working through this. Not sure exactly what it is about you TEC folks (and those of you related to TEC), but I can honestly say that I (who retired from 20 years in IT Management with Nike a few years ago) have never encountered better support on a software issue.

[Steven W]

BTW, one of the things I did with Andy was to give him the html for one of the events for him to test. He created an all-day event with it and was able to duplicate the problem. If you think that’d be help for you, here’s the event text we’ve been working with:
<strong>Maundy Thursday<strong> (<span style="color: #800080;">Violet</span> or <span style="color: #ff0000;">Red</span>)</strong></strong> <strong><a href="https://www.biblegateway.com/passage/?search=Exodus+12%3A1-4&version=NIV" target="_blank">Exodus 12:1-4</a></strong>, (<strong><a href="https://www.biblegateway.com/passage/?search=Exodus+12%3A5-10&version=NIV" target="_blank">12:5-10</a></strong>), <strong><a href="https://www.biblegateway.com/passage/?search=Exodus+12%3A11-14&version=NIV" target="_blank">12:11-14</a></strong>; <strong><a href="https://www.biblegateway.com/passage/?search=Psalm+116%3A1-2&version=NIV" target="_blank">Psalm 116:1-2</a></strong>, <strong><a href="https://www.biblegateway.com/passage/?search=Psalm+116%3A12-19&version=NIV" target="_blank">116:12-19</a></strong>; <strong><a href="https://www.biblegateway.com/passage/?search=1+Corinthians+11%3A23-26&version=NIV" target="_blank">1 Corinthians 11:23-26</a></strong>; <strong><a href="https://www.biblegateway.com/passage/?search=John+13%3A1-17&version=NIV" target="_blank">John 13:1-17</a></strong>, <strong><a href="https://www.biblegateway.com/passage/?search=John+13%3A31-35&version=NIV" target="_blank">13:31-35</a></strong>

[Steven W]

Well, I tried the code change (check http://screencast.com/t/Hhx0lZAuZI to insure I did it correctly) to \wp-content\plugins\the-events-calendar\src\functions\template-tags\general.php and can’t tell that anything changed. I’ve updated to TEC 4.0, TEC Pro 4.0, and TEC Category Colors 4.4.5, but not to WP 4.4 so as not to muddle things (potentially) further. One of Andy’s changes did correct the blank event and I’m now getting the text for the event (i.e., in the Tooltip), but as you can see at http://screencast.com/t/kPNx2BYg4L, I’m still getting the text broken up into lines by punctuation that (significantly?) php recognizes. I also tried changing the ’55’ argument to ‘5’ just in case 55 words was capturing all my fairly short text, but that didn’t change anything either.

We’ve made progress, and seem to be almost there — but I’ve gone as far as I can go without further direction/suggestion from you or Andy…

[Steven W]

I’m on the road at present and have been limited in what I can do on this, but I did make the code change you recommended and can’t tell that it changed anything. I’ll be back in the office tomorrow (Wednesday) and will test more fully, then let you know. Just didn’t want you to think I’ve dropped out here…

[Author]

Posts