BertPC

How was this resolved? Did it just take some time for the credential/client to be recognized? I see in the Google Cloud interface that it may take 5 minutes to a few hours for a client to be available.

We’re using an older theme which does not have a “Theme Options” menu item, so that option won’t work for us. We’re not seeing the IP address thing that was mentioned earlier, either, so that code hack is a no-go. I have one laptop that displays the calendar fine, but another that doesn’t — I think it is indeed a plugin caching issue. The CSS file is not on the web server, but some client browsers have the file cached so they’re ok for now…

I’ll file a ticket with the plugin developers until we can get a copy of the CSS manually saved into that plugin cache folder (another hack).

I’ll add, too, that we were only able to get the PHP limits increased by adding directives to the .htaccess file. wp-config.php and even php.ini didn’t seem to honor those settings. This is what we added to .htaccess:

php_value upload_max_filesize 256M
php_value post_max_size 512M
php_value max_execution_time 300
php_value max_input_time 300
php_value memory_limit 256M

Hope this helps.
-e

• This reply was modified 5 years, 4 months ago by BertPC.

I’ve experienced the same stalling you’re seeing with the plugin (both free and premium versions), as well as the % bar going well over 100% by the time it finishes. I’ve run through a migration three times and each time had to resume it at least 20-30 times for it to finally finish.

This is a major pain, no doubt about it, but I’ve not noticed any duplication of records and the plugin seem to bring over everything it says it will. I, too, reached out to the plugin author and didn’t get much help about the issue – but he was responsive at least. What I did was run the import and tail the progress log directly since the UI log window doesn’t update:

tail -F wp-content/uploads/fgm2wcp-progress.json

I essentially waited at least 5 minutes before figuring the process stalled, then I reloaded the plugin page and resumed again. Rinse/lather/repeat… for as long as it takes for the plugin to complete the migration. It seems to progress about 5% each time, at least for the migration I did.

If I had lots of time on my hands, I’d put a lot more logging in place so there’s a sense for where the plugin just gives up, times out, or whatever. It’s gotta be something that can be mitigated in some way.

For all its failings, this plugin did save us hundreds of hours of work manually copying almost 500 products from old site to new. I looked at other plugins but they don’t seem to have anywhere near the breadth this one does. I just hope it can be strengthened in the weeks/months to come, so it can literally be a one/few-click progress, not 20-30 times that.

Ran two more times, and it’s up to 1656. At this rate I’ll have to run it as many as 35 more times. ugh… I’m gonna try and put some log statements in the code and see where it’s bombing.

Anyone else seeing this behavior?

Keeping an eye on /wp-content/uploads/fgm2wcp-progress.json, I can see that the total is 5883 and the “current” value increments in small amounts (anywhere from 10-30) every several seconds to few minutes, then eventually just stops updating. I’ve run the process four times so far, and it’s only up to 1351.

I’m just hoping to figure out what’s stalling the process so much.

With latest version of the plugin (1.5.3), the new user email has the correct URL, for me anyway.

I’d recommend this change instead to line 50, to preserve SQL injection protection:

$qstr = $wpdb->_real_escape($_GET["s"]);

Tested with WordPress 4.9.8 running on PHP 5.6.

• This reply was modified 6 years, 2 months ago by BertPC.

Very cool, thanks!

I resolved this myself by adding the option manually to the wp_options table. Once I did that, searches included the meta fields I added. This is a fabulous, simple plugin, but I’m afraid for its future if it’s not getting any love from its developer(s).

INSERT INTO wp_db.wp_options (option_id, option_name, option_value, autoload)
VALUES (NULL, 'iusib_meta_fields', 'business_name,business_dba', 'no');

Changing the slug to something else, saving, then back to “events” fixed it for me as well.

It’s weird, after some time the problem with the several “illegal string” messages just goes away. Maybe this is caused by Instagram and their API servers? There must be an error response coming back from Instagram that the Alpine PhotoTile code isn’t handling.

I have the same problem. I’m guessing it’s related to caching, because this seems to happen each time I make a change to the page content. Doesn’t happen when updating CSS, only the content itself.

Warning: Illegal string offset 'hidden' in /home/nhmadehq/public_html/wp-content/plugins/alpine-photo-tile-for-instagram/gears/alpinebot-display.php on line 91

Warning: Illegal string offset 'hidden' in /home/nhmadehq/public_html/wp-content/plugins/alpine-photo-tile-for-instagram/gears/alpinebot-display.php on line 91

Warning: Illegal string offset 'photos' in /home/nhmadehq/public_html/wp-content/plugins/alpine-photo-tile-for-instagram/gears/alpinebot-primary.php on line 188

Warning: Illegal string offset 'success' in /home/nhmadehq/public_html/wp-content/plugins/alpine-photo-tile-for-instagram/gears/alpinebot-primary.php on line 188

Warning: Illegal string offset 'feed_found' in /home/nhmadehq/public_html/wp-content/plugins/alpine-photo-tile-for-instagram/gears/alpinebot-primary.php on line 188

Warning: Cannot modify header information - headers already sent by (output started at /home/nhmadehq/public_html/wp-content/plugins/alpine-photo-tile-for-instagram/gears/alpinebot-display.php:91) in /home/nhmadehq/public_html/wp-admin/post.php on line 235

Warning: Cannot modify header information - headers already sent by (output started at /home/nhmadehq/public_html/wp-content/plugins/alpine-photo-tile-for-instagram/gears/alpinebot-display.php:91) in /home/nhmadehq/public_html/wp-includes/pluggable.php on line 1121

I’ve decided to go with another membership solution at this point. There are some other requirements that the Groups plugin wasn’t really going to help solve.