Neil Mickelson

Thanks for the detailed reply. Unfortunately, I don’t think tags will work — I haven’t found a way to automatically map my iCalendar feed items against Tags when the importer runs…only Categories. Maybe that’s why they just use the post-tags taxonomy…

I might run an experiment that uses the Taxonomy Images plugin to see if I can get images assigned to the Events Category taxonomy and then see if your plugin can handle the Featured Image replacement…

Thanks again!

I haven’t done exhaustive testing, but I can confirm that the upgrade brings the Google Map BACK on a page that uses the Breeze Calendar display shortcode (https://new.sterlingumc.org/breeze-calendar/). I haven’t tested the Breeze Events widget.

Eventually we’ll want to use the Breeze donations widget on our site, but we don’t even have that set up in Breeze yet so we’re good for now…

Thanks!!

(P.S. Leaving this thread open in case you get anything back from Breeze on the jQuery item.)

• This reply was modified 7 years, 6 months ago by Neil Mickelson. Reason: Added P.S

I’m kind of out of my programming depth here, but is there any way to wrap the various calls to Breeze’s functions in a jQuery noConflict functions to avoid the conflicts?

I’m not using the Breeze donation form at all — I’m only interested in the calendar (widget and shortcodes).

Steven – Awesome, thanks for pointing this out! Right now, the plugin is active on the site but not being used for showing Breeze calendar events so you don’t see an issue.

Michael – Can you look at the above and possibly push an update to your plugin? I can test that in a heartbeat.

When you looked at the site, the Breeze Display plugin was still active — that’s what was driving the upcoming events widget in the site footer.

For now, I’m planning on utilizing our legacy calendar plugin (Time.ly Core – All In One Event Calendar) to pushing our Breeze calendar to that via iCal for site display. That approach doesn’t create the display issues that I noted above.

Once we get the site up and running in the new design, I’ll look at trying to rework the staging server to leverage Breeze Display and help more troubleshooting.

OK, one correction to the above post — within the code, there were email addresses wrapped in left and right angle brackets…the browser interpreted that as bad HTML and didn’t render, but they appeared in source.

ANYWAY…I’ve done some more checking and it appears the error is on the the DreamHost side. For some reason, the list email address isn’t coming across in the [name] field unless there are quotes around the actual name. When that happens, an attempt to send to such a list errors out because the URL call to post the message isn’t properly formatted (invalid_name error).

Still trying to get them to fix this on their end…but I know how to work around it now!

One more note from my attempts at trying to understand what’s going on…

I did a bit more testing in the DH Panel because I noticed a couple things:
1. My original announcement list had quotes around the name…but when I created another list with spaces in it, I didn’t get quotes. However, if I then edited the list (making no changes) and hit the button to save, then DH Panel added quotes around the name. Weird, but OK.
2. Because of this weirdness, I decided to grab the results of the call to DH to get the list of Announcement Lists. I did this by adding echo '<pre>'; print_r($result); echo '</pre>'; just before the return statement at the end of the sxss_da_api Get Announcement Lists function.
3. Here is the result:

Array
(
    [data] => Array
        (
            [0] => Array
                (
                    [account_id] => xxxxxxx
                    [domain] => sterlingumc.org
                    [listname] => newsletter
                    [max_bounces] => 5
                    [name] => "Sterling UMC Rapp Sheet"
                    [num_subscribers] => 0
                    [start_date] => 2014-07-10
                )

            [1] => Array
                (
                    [account_id] => xxxxxxx
                    [domain] => sterlingumc.org
                    [listname] => prayer-chain
                    [max_bounces] => 5
                    [name] => "Sterling UMC Prayer Chain"
                    [num_subscribers] => 0
                    [start_date] => 2014-07-10
                )

        )

    [result] => success
)

NOTICE — The returned “name” values from the DH API don’t in fact comply with the output format that the documentation for this call specifies…the name value should have the listname as well as the list’s email address per the function documentation.

I’ve posted a support request/bug report to Dreamhost about this, because it looks like it’s not related to your plugin after all! ??

OK, it appears that I’ve made some progress in isolating what’s going on. Here’s what I’ve found:

1. I added the echo statement you suggested to the plugin code so I could grab the URL.
2. I need to have more than one announcement list set up in DreamHost.
3. Once I added another list, I tried sending to it (it had a simple, one-word list name). I got the same invalid_name error. Here is the post URL for that attempt:

https://api.dreamhost.com/?key=xxxxxxxxxxxxxxxx&cmd=announcement_list-post_announcement&format=php&listname=prayers&domain=sterlingumc.org&subject=Prayer+Chain+Test&message=Another+attempt...&name=Prayers&charset=UTF-8&type=htmlArray

4. I then tried sending to the first of my two lists — the one that had previously been erroring out. This time, it worked! Here is the post URL for the working attempt:

https://api.dreamhost.com/?key=xxxxxxxxxxxxxxxx&cmd=announcement_list-post_announcement&format=php&listname=newsletter&domain=sterlingumc.org&subject=Another+Test&message=Testing+once+again.&name=%22Sterling+UMC+Rapp+Sheet%22+%3Cnewsletter%40sterlingumc.org%3E&charset=UTF-8&type=htmlArray

You’ll notice a key difference between the two — in the successful attempt, the name variable contains a URL encoded list name and related email address in a format that matches the DH API documentation. In the non-working case, the name variable did not have the list name and email in the required format. Looks like there is some subtle error in your plugin code in handling the returned list of announcement lists that means the last item in the “list of lists” will result in a malformed POST URL.

Any thoughts?

OK, it sent correctly from Dreamhost Panel.

I would have to dig more into the plugin code and the DreamPress API to see what might be causing this, but something seems to be slightly off in the translation of the required name attribute from the HTML form into the PHP API call. Not sure why it works for you but not me…perhaps a Dh API versioning issue related to when keys were generated?

Great, thanks. I’ve updated and here’s what I’m seeing:

API error while sending one or more announcements!
Reason: invalid_name
Info:

Per the API documentation, this appears to be an issue with the announcement list name. In my case, the name is “Sterling UMC Rapp Sheet” which comes across in the web interface just fine after the API queries it for display in WordPress. Here’s the HTML:

<form method="post" action="https://scripts.dreamhost.com/add_list.cgi"> <input type="hidden" name="list" value="[email protected]" /> <input type="hidden" name="domain" value="sterlingumc.org" /> <input type="hidden" name="emailit" value="1" /> <input name="email" value="[email protected]" /><br /> <input type="submit" name="submit" value="Subscribe" /> <input type="submit" name="unsub" value="Unsubscribe" /> </form>

I’m going to try and make sure everything is working on the DreamHost end as well by sending a test through their control panel…I’ll let you know what I see in a bit once I give the system time to try and send the message. Panel says it was successfully queued, we’ll see…

Neil

I get the following in a normal WordPress notification at the top of the Dashboard:

Error while sending one or more announcements!

Looking at your code a bit, it appears this is your plugin’s canned error message for any error response from the API.

If there are any WordPress plugins I could use to try and trap the traffic between the plugin and the API at the PHP level, point me to them and I’ll be happy to use one for a bit to try and capture the traffic.

Thanks…Neil

Mosey —

Thanks for the post, and checking out the plugin. I’ll have to take a look at this — I conceptually know what I’d need to do, but I’m not sure whether I could integrated it into the plugin easily without basically rewriting a built-in WordPress function (basically re-implementing listpages to support grabbing and outputting the custom field; I’d like to avoid that in order to be able to easily extend SR-ChildPages if the listpages function gets improved). But, I’ll keep this in mind for a future version.

Cheers…Neil

I’ll give those a shot…

I would add, though, that I did some digging on the TinyMCE site and found documentation for changing the (X)HTML elements and attributes that it will allow. I’ve tried editing these options in the WordPress TinyMCE installation, but nothing seemed to work. Does anyone have any experience with this? It might be nice to have a TinyMCE installation in WordPress that was completely XHTML-ready. Here are some links:

TinyMCE FAQ on HTML Stripping

TinyMCE valid_elements option documentation, including a full XHTML validation string

It would be great if WordPress would allow an easy way of altering these valid_element strings via an admin interface. Maybe that’s something for the hackers list?

Well, I can’t seem to find Roam anywhere…

And I’m aware of Magpie RSS, but I’m really looking for a finished (open source) product I can just put on a server and use…I’d prefer not to have to build my own solution on top of something like Magpie RSS for timeliness’ sake.

Does anyone else have any ideas? Thanks again…

I had similar errors on my actual web host. If I recall, the problem was editing the file with pico; for some reason, it was inserting newlines into the comments after the DB variables. When I corrected this, the “blanks” error went away. If the suggestion of carefully modifying the default wp-config_sample.php file doesn’t work, I’d do a very careful cut-and-paste of the PHP code into a new wp-config.php file and delete all comments and extraneous newlines. Using a text editor that shows newline markings (kinda like Word’s “Show/Hide Para” function) might also help you find the problem.