Support » Plugin: All-in-One Event Calendar » Only certain events imported from .ics

  • Resolved Matt Scheidler

    (@matt6303)



    We have been importing a Google Calendar for 5.5 years. We are now noticing that some events are being imported and others are not. 7 new items were added to the Google Calendar yesterday; four imported successfully and are being displayed on the website while the other three were not.

    I have deleted the feed and added it again, to no avail. I also have clicked Refresh a number of times but that doesn’t seem to do anything – it just says “Refreshing” and spins forever.

    What might cause this behavior? I have imported the ICS file into Microsoft Outlook and the events in question display properly, so I know they’re present and (apparently) formatted properly.

    Thank you for your time!

Viewing 11 replies - 16 through 26 (of 26 total)
  • Plugin Author Sunny Lal

    (@sunny454)

    Hi @matt6303,

    There is no specific configuration change. Default configuration works for most users using PHP 7.1 or 7.2 and in some cases additional memory had to be allocated.

    Late yesterday my host conducted an experiment where they matched PHP modules exactly between 5.6 and 7.2, and then we upgraded the site to 7.2. We got the same result as before, the “Refreshing” text and no completion of the import.

    We’re in needle-in-a-haystack territory at this point, I’m afraid. I have replicated this problem on a different website with a different hosting company, and also on a different website on a different server environment with the same hosting company. If I could get the import function to work on 7.1 or 7.2 under any conditions (site, host) that would be helpful but I haven’t observed that yet. I’m not sure what else to ask, but we’ll keep running 5.6 and I’ll keep trying different things to hopefully find some server/site/host combination that actually does run an import on 7.1 or 7.2 so that we can compare.

    Plugin Author Sunny Lal

    (@sunny454)

    Hi @matt6303,

    In the experiment your host conducted, it proved that the problem persists despite the modules being the exact same. I keep mentioning that the problem is low memory, which validates the results of this experiment.

    Again, the problem isn’t the PHP modules, the problem is the vast amount of memory that PHP 7.2 requires to run, which takes that memory away from applications installed in your website or WordPress installation, causing the Import feed sync operation to hang due to lack of available memory.

    Depenging on the host and it’s available memory, and also it’s memory type and configuration, it will result in a low memory condition for the user (you). What kind of hardware is your host running? What is their memory capacity.. perhaps try an experiment with PHP 7.2 with all the memory that you can possibly allow. Of course this won’t be feasible if there isn’t any extra memory to allot in the first place.

    It could also be possible that the WordPress multi-site on PHP 7.2 also decrease memory available for each site.

    If a solution is not found, you have the option of switching to our web app calendar — it will run on WordPress, but is not dependant on your resources since we host it. You can check it out here:

    https://time.ly/pricing-full-list/

    Sunny, thanks again for all the assistance. I’m looking at this again after the long holiday weekend.

    As a 5th test, I just installed WordPress on a Windows server. Once again the import function works on 7.0 but not on 7.1.

    All-in-One Event Calendar: Undefined property: stdClass::$geo @ C:\inetpub\vhosts\mytestsite.com\httpdocs\wp-content\plugins\all-in-one-event-calendar\lib\import-export\api-ics.php:249 #8
    
    PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 1489453232 bytes) in C:\inetpub\vhosts\mytestsite.com\httpdocs\wp-content\plugins\all-in-one-event-calendar\lib\iCal\iCalcreator-2.20\iCalcreator.class.php on line 8004

    I appreciate the help that both you, and my host, are providing as I go back and forth on your respective support channels. I don’t want to take up so much of your time, or theirs, but I do need to figure this out at some point before the upcoming end of life of PHP 5.6 and 7.0. I would love to see a working website running 7.1 or 7.2 that is successfully importing an ics feed, so that we could compare, but I’ve now tried 5 different WordPress installs on 4 distinct environments and all are behaving exactly the same as far as I can tell.

    Plugin Author Sunny Lal

    (@sunny454)

    Hi @matt6303,

    Thanks for the update.

    The first part of the error is saying it can’t define the class for locating the geocoding of iported events. The reason is because in the next line, it shows that it’s run out of memory, as in previous tests.

    It says that it required 1.4 GB of memory and only 1.3 GB was available at the time of the import. So it seems on this server, it’s also causing the same issue.

    We tested this on various servers also with similar results and the conslusion seems in line with what we’ve discovered with memory usage of the newer version of PHP.

    We have over 100,000 active WordPress core calendar users, many of them are using PHP 7.1 and PHP 7.2.

    I have a test site hosted by BigScoots hosting on a virtual host, and I’ve had to switch my PHP in Cpanel to 7.0 in order for the calendar to work — due to the memory issue. But this makes sense because on virtual hosting there are hundreds of customers using the same server, so memory is allocated and distributed amongst all customers on that box.

    In a dedicated server environment, you will not likely experience a shortage of memory issue. Is your test environment virtual, or dedicated?

    My host worked with me on additional testing today.

    On a test site – an exact duplicate of the live site – we set PHP to 7.1.21, and changed memory_limit to “-1” just to see what would happen. The import did work.

    Finally proving that we could get it to work at all, I then began a bit of trial of error with extremely high memory_limit values.

    For an .ics file with 269 events, 2048M was not enough, but the import did work when we set it to 3072M.

    For an .ics file with 595 events, 3072M was not enough, but the import did work when we set it to 4096M.

    This testing was happening on the same server as the live server, in a KVM environment. The live site and the test site are in separate cPanel accounts with the same settings.

    Perhaps this information is helpful. Thanks again for your time.

    Plugin Author Sunny Lal

    (@sunny454)

    Hi @matt6303,

    Well done on the testing. Keep in mind that each server configuration is different and for some reason, yeilds different results with memory limits and number of event imported. Nevertheless, good work in finding what works for this server.

    Sunny,

    My report is not indicative of success. There’s no way that I can set that high of a memory limit on the live site. I only did it on the test site for testing purposes. For now the site is going to have to continue running 7.0.

    I’ve been trying to stay ahead of the curve, updating all the sites I’m responsible for to 7.1 or 7.2 before the end of the calendar year, and I’m hopeful that a solution for this issue can be found before the EOL for 5.6/7.0 becomes an issue.

    Plugin Author Sunny Lal

    (@sunny454)

    Hi @matt6303,

    To be clear, the issue is with your server, and it’s memory capacity with regards to the version of PHP being used. I’m not sure what you expect me to do or what can be done with our plugin?

    We have over 100,000 active plugin users and there is nothing wrong with the way our calendar performs a basic import of events, which basically reads the import feed provided by a source calendar in ICS format, in accordance with iCal standards, and then lists the events. Nothing more. This can’t be optimized any further than it already has.

    Your report is indicative that there is a problem on your hosting end and there is nothing more I can do to correct this for you.

    I understand that this is a free plugin, and I also understand that I cannot prove where the actual problem is. All I know is the host says it’s the plugin, and the plugin says it’s the host. Keeping the site on 7.0 for now is the right answer for me, and I’ll continue, over time, looking for a longterm solution.

    I do appreciate your time. So many plugins on the WordPress repository have support threads that never get answered. You’ve done a very good job of replying to every one of my replies in a very timely manner. (No pun intended.) I’m just disappointed that after two weeks of efforts by you, my host’s support, and myself, we don’t have an answer.

    Plugin Author Sunny Lal

    (@sunny454)

    Hi @matt6303,

    I do this for a living, and I have encountered this before. Also, I re-iterate the problem is NOT the plugin. Also, your host is completely oblivious to our plugin — so that comment is heresay.

    The problem is the memory configuration on your host. To easily test this, try it on any other host with PHP 7.1 or PHP 7.2. Therein lies your proof.

Viewing 11 replies - 16 through 26 (of 26 total)
  • You must be logged in to reply to this topic.