[Mark Evilsizor]

Regarding 1-3, and 5 here is what I did

– Delete all current events (they went into Ignored)
– Delete all events permanently from Ignored
– Delete the scheduled import
– Test one time import with http://www.lindahall.org, http://www.lindahall.org/event, http://www.lindahall.org/events
o it previewed and ingested 3 every time
o but never bringing in media
– Delete the events and repeat the tests with scheduled import
o it previewed and ingested 3 every time
o but never bringing in the media

So it appears to me that it is respecting the set date ranges. The 177 import must have had something to do with the prior version, or some lingering effect of my failed early attempts.

Once we get the media working, I am ready to try this again on my production sites.

Thanks,
Mark

[Mark Evilsizor]

It will take me a little bit to setup the test for 1-3, so I am responding to the image issue first.

I tried 3 different HTTP/HTTPS header checkers on the Internet and they came up clean for the image you listed and another one. I thought maybe we had a permission issue from inside/outside our network but that does not appear to be the case. See images attached. But this does seem like an interesting thread, perhaps your website is requesting these images from us in some unexpected way which is provoking our Apache server to give a 403? I was unable to recreate it, but I am willing to check Apache configuration details if you believe there may be a problem there.

If you try CURL or WGET do you get the same result?
I do see some differences in the header you show and what I saw from the testing sites, but I am not sure what they mean.

Mark

[Mark Evilsizor]

Sounds good Sky, I have enumerated your questions and answered them below

1.) Can you tell me what you have set in Events > Settings > Imports > “Global Import Settings” and also “Other URL Import Settings?”
See attached images regarding settings

2.) I tried the import with various starting dates in the “on or after” date field, and it always respects whatever timeframe is set in the Events Settings. I even tried setting this a year ago, and it only imported 3 months worth of events from that date.
See attached image regarding import history

3.) Can you also tell me what you are entering for the “on or after” date when you see all 177 events show up? And, are these events all in the future, or are there past events included in that number?
June 1, 2018 – see import details image attached
Most of the events are in the past, basically it ingested (and tries to update) all our past events, and future events within the next 3 months

4.) Regarding the featured images, I am not seeing any of them pulled in. I do most of my testing on an MU site, and the featured images are usually pulled in without any issues. Are you using any kind of CDN like Cloudflare on the site the images are being pulled from?
I also did not ingest any of the images from the client
We do not have any CDN, we do use a cache
The URL seem normal to me: https://www.lindahall.org/wp-content/uploads/sites/5/2018/05/QC517-A49-1804-pl-4-4-300×135.jpg.
I am able to CURL it on the client (our client and server are Linux)
I am able to click on a link and see the image on my phone (outside our network)
Perhaps the aggregator software is thrown by the https protocol?
Perhaps something in our media name is unusual?

5.) Can you explain in more detail what you mean by “clicking the Previous button seemed to effect a run?” Do you mean your browser’s “back” button? I tried this in Chrome/Mac and it does not restart the import when hitting “back” for me. It starts at the beginning with “select import type.”
I mistyped. I meant that when I clicked the Preview button, it not only did a preview, it actually ingested all 177 events.

Mark

[Mark Evilsizor]

Subsequent to the preview/import I have just clicked Run Import from the scheduled imports tab and it does run and the fuel bar churns through the records and ends appropriately. But

– It said it updated 177 even though no records were changed on the source
– It did not bring in the media
– It does not appear to be respecting the Events On or After setting

Mark

[Mark Evilsizor]

When I was doing my testing on 6/1/2018 the client and the server were both on 4.6.17. Now both are on 4.6.18.

Also as I have been trying it on the test server, I have used 1 site in an MU WP network as the client while the server was https://www.lindahall.org – i.e. 1 site on a different WPMU network.

When I do a preview now, it is showing all the events from https://www.lindahall.org rather than only showing events from the selected date forward. So that set of events to import would be 177. And even though I clicked preview, it actually did bring the whole 177 in. Some thoughts on this

1.) May be the TEC 4.6.18 fixed the hanging problem?
2.) A little disturbing that clicking the Previous button seemed to effect a run
3.) Appears to be a bug that it did not respect the Events on or after date
4.) It did create all of those events, which is an improvement, but it did not bring in their media. Can you try this with 1 site of a multisite network as the client and using our site, https://www.lindahall.org as the server? In my testing on Friday, when once event was ingested, the media was not. Perhaps with a multisite client it is not bringing in or writing the media records to the right place or at all?

Thanks for your help,
Mark

[Mark Evilsizor]

This reply is private.

[Mark Evilsizor]

This reply is private.

[Mark Evilsizor]

This reply is private.

[Mark Evilsizor]

I initially entered: http://www.lindahall.org/events

When I looked back into the settings it had changed it to http://www.lindahall.org/events
But most accurately it should be: https://www.lindahall.org/events

Thanks,
Mark

[Mark Evilsizor]

I had the exact problem today but on a linux box. I am using WP Multisite and was trying to import from one site to another. Restarting Apache and rebooting the server did not stop the job.

I came to believe that the WP Cron was the key to trying to kill this job. I tried
– Renaming the option_name field value from _transient_doing_cron to _transient_doing_cronX
– Installing the WP Control plugin and deleting the following 3 WP Cron entries
o tribe aggregator
o tribe_queue_ea_import_events_cron
o tribe_aggregator_process_insert_records
I did not restart apache after this and perhaps I should have. But deleting the cron jobs did not kill the job, I continued to see the stuck process

So I used Updraft Plus to restore this one site, and all plugins across the network to earlier today. This returned The Events Calendar to the state it was in prior to installing the Aggregator license key. And it restored this one site’s options table. This effectively killed the job and my sites are now functioning properly.

There must be a better way to stop an errant job, but it was killing the performance of my sites and the backup was a couple hours prior and no content had been edited since then so I was happy to restore proper functioning of my network.

[Mark Evilsizor]

I came to believe that the WP Cron was the key to trying to kill this job. I tried
– Renaming the option_name field value from _transient_doing_cron to _transient_doing_cronX
– Installing the WP Control plugin and deleting the following 3 WP Cron entries
o tribe aggregator
o tribe_queue_ea_import_events_cron
o tribe_aggregator_process_insert_records
I did not restart apache after this and perhaps I should have. But deleting the cron jobs did not kill the job, I continued to see the stuck process

So I used Updraft Plus to restore this one site, and all plugins across the network to earlier today. This returned The Events Calendar to the state it was in prior to installing the Aggregator license key. And it restored this one site’s options table. This effectively killed the job and my sites are now functioning properly.

I am still wanting support for
1.) How to properly kill an import job if it runs amuck
2.) How to properly enable 1 WPMU site to aggregate events from another WPMU site on the same network. As stated above the preview worked perfectly, but the actual import just hung. One item which I wonder if it was the problem is that the parameter defaulted in http:// in front of the site I entered, but my sites are all https:// now. The preview still worked but maybe this loused up the actual import job?

[Mark Evilsizor]

Deactivating the WP MU Domain Mapping plugin, and using WP inherent URL to site mapping ability resolved the issues with the admin pages of The Events Calendar.

Thanks for your research and help on this issue,
Mark

[Mark Evilsizor]

Andras our notes crossed. I reviewed your finding regarding not needing a domain mapping plugin anymore after WP 4.5+ and this is very promising. I am testing it on our staging server and it looks like this may be the solution. I will do some more testing and if it goes well, roll it out to our production server.

Thanks for your help, I will post updates.

Mark

[Mark Evilsizor]

Thanks for investigating Andras.

I have created a support ticket with MU Domain Mapping as well. If you find a fix within The Events Calendar that would be ideal. If not, I would appreciate any technical information to provide the authors of the Domain Mapping plugin so that they could fix their plugin if the error resides there.

Thanks,
Mark

[Mark Evilsizor]

This reply is private.

[Author]

Posts