Forum Replies Created
-
Posts
-
Excellent! We got it and responded via email. Please let us know if you have any more questions, or for some reason did not receive the response.
Cheers!
- Brook
Alright Russel I think we figured it out.
The error I got above was erroneous and related to something else, hence why it produced a different message. The exact same error message and circumstance you are experiencing has been reproduced on certained servers, particularly shared hosts.
Those servers do not support PHP’s file_get_contents() functions, and it would look like your server is among them. Part of our iCal importer uses a third party library for processing iCal files, and it uses that function. However, we are going to swap that out for one that is supported by more servers.
This fix is slotted to be released with the next version of our plugin, just after 3.12. 3.12 is due for release in less than a week, and all changes to it are already in place. We are thoroughly testing it now to try and make sure no new bugs were introduced, hence why we can’t make any more changes.
Please let me know if you have any questions or concerns. Thanks!
- Brook
No worries Chris! I’ve done my fair share of freelance and know exactly how that goes.
If you do need anything else though, just ask. We’ll be here.
Ta!
– Brook
Thank you Russell. With that .ics file I was able to reproduce an error. Although mine was a generic “An error occurred.” I am logging this for our iCal developers to look at further.
At this point we are assuming this is probably a bug in our code. It can take a bit longer to hunt down bugs than a usual support topics. I will keep you posted, but it might be a few days before I have a true status update.
Please let me know if you have any questions in the mean time. I realize you are a recent customer of the iCal importer. If you wish to get a refund while we work this out please don’t hesitate to ask. I am very sorry for the oddity and inconvenience.
- Brook
You’re very welcome Dennis. And again, I apologize for the inconvenience. Sometimes you just don’t think about things like “what will happen if someone visits every month between now and 85000 AD?”
I can understand your server not liking such an enormous table, and it impacting basic WordPress functions. For whatever reason that’s how WordPress stores them. I agree, it’s a bit odd. Does clearing the transients as outlined in that link help fix it for now?
- Brook
For sure! I would be happy to give you a status update.
Our plugin is on a 6-10 week release cycle. Once a bug is confirmed the soonest it can be fixed is 6 weeks. But, some times it is longer. If you are reaching the last couple weeks of a release cycle we can no longer squeeze any change in, as all changes have already been made and they are under going testing.
In this case our plugin has already neared the end of the release cycle and we can squeeze no further changes in. I will do my best to get it included as soon as possible. But, we do have to prioritize bugs based on how many users they impact, and in thise case this bug is only impacting one user. 🙁 I hope you can understand, compared to bugs that affect thousands or hundreds of thousands of our users it is naturally a lower priority. I will let the devs know there is continued interest in getting this fixed. Perhaps we can identify a way to fix it before bundling the fix with a true update to our plugin in a month or more. I will let you know.
To shorten the above, the bug has not yet been patched and it may be a number of weeks before it will be. But, as soon as a fix is ready for release we will post here and let you know. In the mean time, manually creating those two events is the only known work around.
Please let me know if you have any questions. Thanks!
– Brook
Thank you Ramon! I was now able to reproduce this problem and investigate it. It looks the Templatic widget is adding in applicable limitations to other widgets WP Query :
where pm.meta_key ='post_city_id' and FIND_IN_SET( 1, pm.meta_value )The meta ‘post_city_id’ will only apply to listings in Tevolution’s Directory widget, yet Tevolution is accidentally adding it to other widgets queries including our calendars.
I can see no way to write a snippet that will fix this. 🙁 To be frank, this is not our plugins fault. Their code is running when it should not, and mucking up the works. However, I don’t want you to have purchased something you can not use. So I want to offer you a refund if you are keen on that. The only other options besides a refund would be to ask Templatic to fix this and wait for them to craft a fix. Or, to use a different theme or layout.
Will one of those options work?
Cheers!
– Brook
Howdy Russel,
I agree for sure, this is unlikely to be a file permissions error if the media importer shows them sucessfully imported.
We have had at least one dev on PHP 5.6 test the iCal importer recently. All the same I am requesting that some folks on our team with 5.6 try to reproduce, just in case. Would it be possible to get the URL of the file you are trying to import? It can be shared privately be checking the box “Set as private reply”.
I am sorry for the inconvenience Russel. This is a very puzzling issue. I have asked them team if they have any more ideas as well, and no one can see why it would not be working for you once all of your plugins were disabled and you had switched themes.
I will get back to you with our test results. If you can think of anything you might be doing that is unique or different than the usual, please share. That way we can do that as well while trying to reproduce.
Cheers!
– Brook
Thanks for your understanding Dennis! We definitely did not design this with the notion that it would pack a database with a gigabyte of data. But now that the need has arisen, I will talk to our devs about adding a throttle.
So, your message seems to be missing a link or something: “Then, I would clear the transients using a strategy like this. That will shrink your table back down to a reasonable size.” I’m thinking there was something between those sentences, not the old “left as an exercise for the reader” ploy.
Ahh yes. It was a link, but those don’t show up in the email transcripts. Here ‘s the link: http://stackoverflow.com/questions/10422574/can-i-remove-transients-in-the-wp-options-table-of-my-wordpress-install
I really hope I don’t have to drop the caching — we have a lot of events on this site, and a lot of other custom code, so everything that helps speed is good. I’m going to put in one of the caching plugins soon — I guess I could disable your cache then, right?
Installing a different caching solution will render ours moot. That’s why the caching is a toggle on our end. Most caching plugins do appear to be fully compatible with our calendar and its ajax requests. A lot of our users use W3 Total. But, it does have at least one setting which is incompatible: Minifying JS/CSS assets. Our assets are already minified, and minifiers often break things when run twice. As a bonus, this caching will will speed up other areas of the site as well. However, you might still find you have a giant cache if a lot of bots are hitting your site, causing the server to cache all of those pages. But, typically those caches are not in the DB they are stored as HTML files.
Please let me know if you have any more questions. Thanks again for bringing this to our attention, it’s definitely something we will fix for future users. But, in the mean time hopefully a caching plugin will prove a good workaround for you.
Cheers!
– Brook
Howdy Erika,
I am happy you reached out. I just searched our inbox your email, your organization name, and your website. In all cases it returned 0 results. Indeed, we never received your email/submission. 🙁 Sorry to keep you waiting this long.
Could you please try refilling out the form? Sometimes the internet dips for a moment when people submit forms, or some other random event can happen, and can cause a form to not go through. It’s just the nature of the internet. Once you’ve submitted it again please let me know and I can double check that we received it. If you share the email address you sent it from in a private reply here, I can definitely look up your submission.
Thanks for your patience. I look forward to helping you get approved after such a long wait.
– Brook
Wow! That is a lot records.
I can actually see how this would happen with Month Caching enabled (setting found in WP Admin > Events > Display). Basically when you enable that, the HTML for a given month is stored as a WP Transient. When someone tries to view that page, the server only needs 1 DB query for the HTML instead of the 30+ that are unfortunately required to render Month view. But, if a bot (computer) was crawling your website it could attempt loading every month from now until the year 85000 AD, one million months in the future. In such a scenario you would indeed get 1 million transients in your database :-/.
In short, a computer or bot has likely crawled over a million pages, causing over a million months worth of cached pages to appear as transients. Did you try to spider your website with a bot? Typically search engines would not try anything close to a million months, especially when our robots meta tags tell them not to index empty month view pages. So, this is likely the result of a manual spidering. If you didn’t do it someone else might have. It might be worth stopping them with an IP block, that much crawling is sometimes the sign of a hacking attempt. If your server logs show a million+ requests from an IP you don’t recognize, a block is probably appropriate.
How to resolve this
First of all, I would make a backup of your database. Always a good idea before dabbling. Then, I would clear the transients using a strategy like this. That will shrink your table back down to a reasonable size.
If you are worried about another bot crawling your site and causing the problem to resurface, then you could disable month view caching (WP-Admin > Events > Settings > Display).
Finally, I am going to check with our developers and see if it makes sense to limit how far into the future/past we cache Month views for. Typically pages in the distant past or future don’t see a lot of users, so for the majority of people this will likely help in preventing this. That might be a good improvement we could plan.
Does that all make sense? Will that work for you? Please let us know.
Cheers!
– Brook
Interesting. I appreciate all of the details you shared.
One thing to double check with file permissions is that the user and group are both correct. On plenty of servers if you FTP into a site and create or alter a folder, it will change the owner of the file. Sometimes it changes the user, sometimes the user and the group. And while you’d something think crazy permissive permissions like 777 would make this a non-issue, a lot of shared servers have security scripts that disable overly permissive files from working at all. So granting too many permissions on said server can actually cause a new problem with the exact same symptom. If you can, please make sure that PHP’s tmp or file upload dir has the proper permissions + user + group, and that the /wp-content/uploads/ directories all do as well. You might need to consult NetSol to assist with this, particularly if your server is running PHP via FastCGI. They can let you know what the proper user/group permissions are.
One more diagnostic test makes a lot of sense to try, perhaps even before the above. Can you just try uploading a old file through WP’ Media importer. Does it upload succesfully? Do you see the old iCal files you were importing in your WP Media library?
Again, please let me know if you have questions while diagnosing. I’ll be here to help.
– Brook
Hey Ramon,
You’re super welcome! I was giving this a test. It is unclear to me which of the Templatic widgets you are using to display the “business listings”. I do not show a widget named that. Could you please double check what the widget is called in WP Admin > Appearance > Widgets ? I have got the rest setup and ready to test.
Thanks!
– Brook
