capnhairdo

Forum Replies Created

Viewing 15 replies - 1 through 15 (of 16 total)

  • I noticed this too. According to the W3C validator:

    https://validator.w3.org/feed/

    The <encoded> node triggered a “Undefined channel element” error.

    I commented out that code in the plug-in, and the plug-in still seems to work fine, and my feed now validates.

    Thread Starter capnhairdo

    (@capnhairdo)

    Actually, it does, after I fixed these two issues:

    https://codeontrack.com/fix-wordpress-and-plugins-fail-on-update-ssl-certificate-problem-unable-to-get-local-issuer-certificate/

    https://jehy.ru/articles/2009/12/29/wordpress-ftp-update-trouble/

    I would delete this thread, but the forum won’t let me.

    How do I send it to you? Thanks for being willing to take a look.

    I’m having the same issue as of this morning. We’ve been running this plug-in for ages on our WP site. Everything was working through yesterday. Today, I’ve got the WordPress blank screen of death. Had to hack my MySQL database to disable all plug-ins, then re-enable them one-by-one. All was fine until trying to re-enable Tweetable, which yields: “Plugin could not be activated because it triggered a fatal error.”

    The plug-in was working fine until now, and I can’t think of anything that’s changed since yesterday. Stranger still, the plug-in works on the development version of the site on my testing server, which is virtually identical to the production server. And Twitter is definitely up.

    Tried uninstalling and reinstalling Tweetable…no luck.

    Currently running WordPress 2.9.2. Haven’t upgraded anytime recently. Confirmed the host is running PHP5.

    redwallhp, I’d be happy to send you a copy phpinfo() output, if you can tell me where to send it. Thanks for your help.

    I second swosko’s praise for your plug-in. Simple and straightforward, it was pretty much exactly what I needed for a client’s site who just didn’t want to have keep updating his résumé in so many places. He wanted to show his LinkedIn résumé almost verbatim, with just a couple of items removed, and your plug-in did this with the least meddling.

    Just a couple quick suggestions for possible enhancements:

    ? Remove LinkedIn-specific stuff like “My connections” link.

    ? Strip out the “more” and “less” links that may appear in Past Experience section of the Summary block.

    * Add some options for the output of the resume, such as showing or hiding certain block and individual elements (e.g. the Summary). Perhaps beyond the scope of this plug-in…

    * Consider adding a filter hook so people can do further modifications to the output code. Something like this:

    function lnhr_stripout_hresume($content) {
...
  $hresume = apply_filters( 'lnhr_resume', $hresume );
  return $hresume;
}

    For my purposes, I added the filter hook mentioned above and then did some further parsing outside the plug-in to remove unwanted elements. I used PHP DOMDocument to convert the résumé so I could find and remove nodes without complicated regexes (why don’t more people do this?).

    // tidy up output of LinkedIn hResume plug
add_filter('lnhr_resume', 'lnhr_tidy');

function lnhr_tidy($content) {
  $doc = new DOMDocument("1.0", get_option('blog_charset'));
  $doc->loadHTML($content);
  $xpath = new DOMXPath($doc);
  DOMremoveHTMLElements($xpath, 'id', 'overview');
  DOMremoveHTMLElements($xpath, 'id', 'additional-information');
  DOMremoveHTMLElements($xpath, 'class', 'adr');
  DOMremoveHTMLElements($xpath, 'class', 'actions');
  DOMremoveHTMLElements($xpath, 'class', 'organization-details');
  DOMremoveHTMLTags($doc, 'hr');
  $content = preg_replace('%^.*<body>|</body>.*$%si', '', $doc->saveHTML());
  return $content;
}

function DOMremoveHTMLTags($doc, $search) {
  $tags = $doc->getElementsByTagName($search);
  $tagsToRemove = array(); // https://us2.php.net/manual/en/domnode.removechild.php#90292
  foreach ($tags as $tag) {
    $tagsToRemove[] = $tag;
  }
  foreach ($tagsToRemove as $tag) {
    $tag->parentNode->removeChild($tag);
  }
}

// https://www.php.net/manual/en/domdocument.getelementbyid.php#96500
// https://us2.php.net/manual/en/domxpath.query.php
function DOMremoveHTMLElements($xpath, $type, $search) {
  $elements = $xpath->query("//*[@$type='$search']");
  if (!is_null($elements)) {
    foreach ($elements as $element) {
      $element->parentNode->removeChild($element);
    }
  }
}

    Cheers, and thanks again for the nice plug-in!

    Thread Starter capnhairdo

    (@capnhairdo)

    See this solution.

    Note that this gets rid of the widget entirely. See unregister_sidebar_widget for a version that disables specific instances of a widget.

    But what if you want to get more specific still and disable widgets on a template-by-template basis, rather than globally? I did–wanted to disable (all instances of) the Recent Posts widget, but only in the home.php template (where it would be redundant).

    To do that, I had to get my hands dirty and wrote this code at the top of my template file:

    foreach ($wp_registered_widgets as $widget) {
  if ($widget['name'] == 'Recent Posts') {
    unset($wp_registered_widgets[$widget['id']]);
  }
}

    Peter, just sent you some suggested changes to the code that seem to fix this problem, as well as add some more features. Let me know what you think.

    I think I might have a better solution that doesn’t involve changing the output of image_send_to_editor() at all. Can I get your email address so I can send?

    I don’t think replacing id with id_base will necessarily work. Correct me if I’m wrong here…

    image_send_to_editor() is a filter function hooked to ‘image_send_to_editor’. That means it may get called several times, if anything else invokes that event. I’ve noticed that for me, it gets called once by the media uploader (media.php) when it tries to add a caption, and then again when it actually sends the image content back to the page.

    The filter function normally receives image HTML code and passes back the same. Your version replaces the image HTML with a JavaScript array. Thus, it should ONLY do this when you know for certain that you’re passing data back to your image widget. In all other cases, it should return the image HTML. Otherwise, you’ll get JavaScript where you don’t want it.

    So I said that in my case, the filter function gets called multiple times, the first time when media.php tries to add a caption, and the second time when it sends the data back to the image widget. In both cases, the referer is the same and id_base is the same. So checking for id_base doesn’t work; it matches both times, and you get a JavaScript containing a JavaScript array back, instead of a JavaScript array containing an image.

    Checking for id as you had it before was more correct. That ONLY happens on the second call, for some reason.

    And you’re right that the PHP version makes a difference…turns out my live box is running PHP4 (dang it, MediaTemple, why do you default to that?). Could change it to 5, like my dev server, but prefer to finish troubleshooting this.

    Windows boxes definitely have a $_REQUEST object, which includes $_POST. That’s PHP, nothing to do with the platform.

    Anyway, the referer is fine. What’s NOT fine is the widget object itself. Like I said, it’s $this->id that’s not returning a value. All the other object variables are fine except number, and match between my dev and live servers. Why just those two vars are missing, I don’t know.

    You seem to be onto it with changing the $this->id to $this->id_base. That has a value of “widget_sp_image” on both. But that’s specific to the widget, not the instance. Is that going to be a problem if you have multiple instances of the widget?

    On live server, the widget object is missing some values. $this->number and $this->id both return false. On my development server, I get 3 and widget_sp_image-3, respectively for those vars. Some glitch with the widget object?

    I tried turning off all the other plug-ins…that doesn’t seem to be it.

    Strangely, it works on my development server with everything almost exactly the same as my live server.

    Problem seems to be with this line:

    if (strpos($_REQUEST[‘_wp_http_referer’],$this->id)) { // check that this is for the widget. SEE NOTE #1

    $this->id appears to be empty to have a value, so there’s no match, and nothing is returned to the widget. Why the widget name (this->id) is disappearing, I don’t know. (I don’t know what NOTE #1 is, but I understand why you need to do this check–so you don’t return the JavaScript array to other functions calling the image_send_to_editor() function.)

    BTW, using WP 2.8.4. Windows XP. Tried with FireFox 3, IE8, Google Chrome, Safari 4. Same result in all, except that in the last three, the “Add an Image” box just goes blank when you click “insert into post”. No JavaScript errors showing up in FireFox error console.

    Thanks for checking it out!

Viewing 15 replies - 1 through 15 (of 16 total)