rich_c

Thank you alchymyth. That worked.

I guess the functions get_permalink(), the_title(), etc., change the _POST data, in addition to returning the data. I noticed that ALL the last post shortcode examples I found on the internet did the same thing.

Odd that no one had ever noticed that when you try to edit a page with the code in it, it “takes over” the edit and redirects you to the post itself, not the original page.

If the author updates his plugin he will have something unique.

No warnings in PHP error file. When I get a chance to put it back on a test server I will post the error here.

I reverted to 3.0.95. Is there a data format change between the two versions?

OK here’s what the problem was:

The URL in the application was correct.

However the site was not yet live. On IIS, you can set several index documents, and set the preferred order. Before any of my PHP sites goes live, I set the order as follows:

index.html
index.php
index.htm (kept for some people who still use this archaic extension)

Then, when you visit ‘https://www.domain.tld’, you get the “splash page” rather than the full site. The site can be tested by specifying ‘https://www.domain.tld/index.php’.

I changed the order of the index documents in the middle of the night as a test, and the Publish, Upcoming Events, and other sub-plugins started to work.

I had previously tried setting the application URL to ‘https://www.domain.tld/index.php/’ both with and without the trailing slash, and neither worked.

So for anyone else in this situation, the facebook application seems to need a URL that ends in a directory with a default index document in order to work, not JUST a valid and correct URL.

I could not see the thumbnails in my custom theme either. I traced it down to plugins/nextgen-gallery/css/nggallery.css line 312. I commented out “overflow: hidden;” and my thumbnails appeared.

/* ----------- Sidebar widget -------------*/
.ngg-widget,
.ngg-widget-slideshow {
	/* overflow: hidden; */
	margin:0pt;
	padding:5px 0px 0px 0pt;
	text-align:left;
}

I like to comment out stuff at first rather than just deleting it, in case it causes a problem somewhere else and I need to revisit it later on. Maybe in some other themes there is a reason for it. ??

I don’t know why it didn’t work on my 5.2.4 version of PHP, but it didn’t. Eliminating empty() also solved other problems I was having in getting the widget to display the correct data on the page.

If you search through the PHP changelog for empty() you will see that there have been enough issues with it that I think it’s worth avoiding.

Anyway your new solution is very elegant. ??

Did you also fix the errors on line 35 where it should be

$events_link = ( $instance['all_events_text'] != '' ) ? em_get_link($instance['all_events_text']) : em_get_link(__('all events','dbem'));

instead of

$events_link = ( $instance['all_events_link'] != '' ) ? em_get_link($instance['all_events_link']) : em_get_link(__('all events','dbem'));

The problem is that you apparently can’t use empty() on an array element. For array elements with a value of ” empty() will return false. Not sure if this is a bug in PHP or not, but converting the tests to good old (instance[‘element’] == ”) works fine.

I’m not getting any errors. However it looks like the form data is not getting saved to the database. The defaults are being written, and if I change the default that’s what I get back in the form after saving. The new default is also what goes into the database for that instance.

So it seems like there’s something hinky in the $new_instance array when update() is called.

Hi, Thanks for responding. I’m using 3.0.9.

Also it seems that the calendar widget does work; it’s only the events list widget that doesn’t.