LauraSuzy

I also had this problem. It’s stored in the wp_options table. You can see what is there with this query:

SELECT * FROM wp_options WHERE option_name = ‘DatabaseBrowserQueries’

and can remove it by running:

DELETE FROM wp_options WHERE option_name = ‘DatabaseBrowserQueries’

How can we determine if port 587 is blocked by our hosting provider? Just submit a ticket to ask? Or is there a programmatic way to figure it out?

I am having the same problem, with a site hosted at HostMonster. I have tried both the TLS and SSL settings, and also port 25, as per the suggestion of this article (https://wphowto.net/gmail-smtp-plugin-for-wordpress-1341), but in every case it takes forever to get a response when I try to send the test email, and when it finally does come back, it has the “Error notice: stream_socket_client():” error.

Can you help?

Here’s the server info:
OS: Linux host178.hostmonster.com 3.12.65-20161020.132.ELK6.x86_64 #1 SMP Thu Oct 20 23:36:20 CDT 2016 x86_64
PHP version: 5.6.29
WordPress version: 4.7.2
WordPress multisite: No
openssl: Available
allow_url_fopen: Enabled
stream_socket_client: Available
fsockopen: Available
cURL: Available
cURL Version: 7.24.0, OpenSSL/1.0.0

Did anybody figure this out yet? I have had some success adding a height attribute to the advps-slide div, and also noticed that the bx-viewport height is listed as 23, but it’s right in the HTML style for that tag.

I tried running a CSS validator and reuploading the file, and the changes seem to be working now. The weird thing is, the only changes I made after seeing the CSS validator results were not things I had changed before – they were things that were already part of the CSS when it was working as it was originally designed. So it’s still a bit of a mystery to me as to why it was cached before and is not now (I can see the new comments and such I put in the file when I request the URL), but I am glad it’s working, nonetheless!

I’m having the same problem, and actually trying to edit the same line of WooCommerce CSS! I searched, but I don’t see the same kind of closing bracket errors in my file. I am using the Woo MyStile theme, and they recommend you put any new css in the custom.css file, so I put in

ul.products li.product { width: auto !important; }

to get it to override the file at
https://www.rijigreen.com/wp-content/themes/mystile/styles/green.css
but it doesn’t take my changes. I am trying to get it to display the product images at their actual size instead of choosing a width percentage at
https://www.rijigreen.com/shop/

I also tried manually editing the green.css file, FTPing it over the existing green.css file, and when I request that CSS file in the browser, I’m getting the old file, with no changes. But when I SSH in, the file for sure has the changes I made. I don’t have any caching plugins running at all.

What else could I be missing that would cause my changes not to take effect?

I have the same problem even though I haven’t upgraded to WordPress 3.8 yet. I think hostmonster just upgraded the PHP version, and I noticed the campaign didn’t go out then. At that point I was running AutoChimp 2.02, but I just upgraded to 2.15. After fixing a PHP configuration problem, I got the plugin to activate, but it’s not creating the campaigns or sending the emails.

Incidentally, my Add to Facebook plugin doesn’t seem to be working, either. Any suggestions?

I found a fix for activation by editing the .htaccess file – despite cpanel saying we were on PHP 5.4, phpinfo showed 5.2, and the .htacess file change fixed it.

I got the plugin upgrade to activate, but unfortunately, my post is not getting sent as a campaign email now, though. Any ideas where I can look to figure out why? All the AutoChimp settings seem to be correct, and I’ve created a new post and tried to get it to send, and it did nothing, and I can find no errors in my PHP logs.

Thanks Zmarsh! I was getting the same error despite my control panel saying I was running PHP version 5.4.24, but my .htaccess file has this in it:
AddHandler application/x-httpd-php5s .php

So changing it to php54 allowed the AutoChimp 2.15 plugin to activate. Thanks!

I have located the wp_options table and see that my theme’s admin pages are correctly saving the option values to the database, but my theme was not retrieving them. There was some code in the page.php file setting variables using get_options, and I just changed that because get_option itself seems to retrieve the correct value.

So I was able to get my site looking the way it should again, however, I still have no idea why it’s ignoring index.php!

I have the backup. Right now, the site is running on my renamed version of the old theme (prior to the update that broke the way everything looked). The Academica theme still exists in a separate folder, too.

Since the Academica theme still exists on the system, I realized that there are places where the function names, special widgets, admin settings, etc. would be still using the Academica naming system. I went through all the php files and changed the names, and was able to at least save the settings as a distinct value related to my new theme, but the home page is still using page.php instead of index.php (which calls the slideshow).

I wonder if the presence of the old and updated Academica versions in my themes folder could be messing me up?

I thought about using a child theme, but I was afraid that if the parent got updated, it would end up changing my child, even though it wouldn’t overwrite my style.css. The last update they totally changed their template names and everything! Some files completely disappeared… it was a dramatic update.

So… given that I *didn’t* use a child theme (I customized this thing a year ago and only learned about child themes last week!)… what’s the best way to see if I can fix it?

One thing I don’t understand is how the theme’s admin files (which add a menu to the left side of the dashboard so you can set theme customizations, such as which files should be included in the slideshow) actually save the settings. Is it stored in the database? And if so, I wonder if there’s some remnant of the old theme name in there somewhere that I need to also update to make it work? Any idea what tables or wordpress api items I might look in?

Well, I found something that tells me it definitely is a date cutoff, but how do I set the value of the preloadEnd variable? When I view the source of the calendar page in IE, I see this in the javascript:

"preloadStart":"20120728","preloadEnd":"20120907"

at the end of the _onload() function on line 10. This is in the source of the gcalendar-wrapper.php file in the plugin.

I tried appending a preloadEnd parameter in the Google embed code on the plugin settings page, and I see that is getting appended to the URL that is called for the iFrame, but id doesn’t seem to be changing the values in the javascript init. Firefox apparently ignores the preloadEnd date, because the same code is showing in the source when I view it via Firefox.

Ideas?

Here’s some more specific information – I only see the problem in IE, and I have version 9.0.8112. It works fine in Firefox. In IE, I see events from all 3 of my Google calendars, but ONLY up till 9/7/2012 – events after that date don’t display.

I am testing the calendar now on the posts page, you can see it here:
https://www.compassclasses.com/5-days-remaining-for-regular-registration/

Is there some sort of 3-week event window limit for IE? I tried creating a bunch of test events to see if it was limited to a certain number, but so far it seems like a date restriction.

Help?