morgaine

Same problem here, using WordPress 2.8.5. Feed should be populated with full posts, not just excerpts. No images showing, although some seem to get the images in Google Reader. Not using hotlink protection. Would like a solution, it’s bugging me for quite a while now.

Same problem here, using WordPress 2.8.5. Feed should be populated with full posts, not just excerpts. No images showing, although some seem to get the images in Google Reader. Not using hotlink protection. Would like a solution, it’s bugging me for quite a while now.

I now use Sociable Zyblog Edition which doesn’t show this problem.

The issue is illustrated in this picture. It’s the custom field ‘sociable’ displaying where it should not, at least not as I understood the use of custom fields, when I read “custom fields can be used to add extra metadata to a post that you can use in your theme”, and as illustrated on using custom fields. The reason I linked to Trouble with Custom Fields in 2.0 is because I think it’s somehow a related problem, and people were indicating key values could be hidden, which can perhaps been done in the plugin, instead of in the wp core files. The problem, where _encloseme, _pingme and _wp_page_template were visible, where they shouldn’t have been, was solved in later version of wp by the way, but now seems to be back for your key (sociable).

One more thing, since this problem only popped up after having upgraded to wp 2.7, and the latest version of sociable, and not before, even though I was using the exact same code in my post template, something must have changed in either wp 2.7, or in the sociable plugin itself.

I imagine other users that are using custom fields might experience the same problem. Perhaps there is another plugin doing pretty much the same as yours without having this problem, but since I have been using this one for quite some time, I thought I’d signal the problem instead of just using another plugin.

Another problem, when using XHTML 1.0 Strict as one’s doctype, is line 696 of sociable.php

I changed

echo '<script language="JavaScript" type="text/javascript" src="' . $sociablepluginpath . 'wists.js"></script>'."\n";

into

echo '<script type="text/javascript" src="' . $sociablepluginpath . 'wists.js"></script>'."\n";

in order to have my site validate.

It’s not exactly a new problem, I believe this support question might be related somehow, but I’m not a developer.

I’ve been happily using the Sociable plugin for quite some time, and this problem arose only after upgrading to 2.7. I didn’t have any problem before, even though I was using <?php the_meta(); ?> as well. I’m not sure where to look in order to try and fix things myself. Either something in the core of WP has changed, or in the Sociable plugin itself.

For now I’m using an out of the box theme, instead of the one I kind of built myself, but it really is a pity I’ve lost all of my custom meta data.

In the latest version of Sociable, the above described error has reappeared, for Ratimarks. It breaks validation, so I changed it manually, but perhaps you can fix this in a next release?

I can accept it when you say it’s my problem, and you don’t want to solve it. I don’t accept however that you say these meta values were intended for this. In WP itself it states: Custom fields can be used to add extra metadata to a post that you can use in your theme, with a link to using custom fields. The examples given there are exactly the things I use.

It should be possible to have an option never to display certain data, as they’re only for internal use.

I have the same problem, only on the main page of my blog (https://blog.morgaine-lefaye.net) where I use <?php the_meta(); ?>

Removing <?php the_meta(); ?> isn’t really an option for me I think, because I use it to display quotes, mood, and other custom fields. On my front page there isn’t any sociable code I’ve added. The wp-o-matic also has the same problem, but at least once I delete the values it generates, next time I update my post, they don’t reappear. Any ideas?

It happens only after having upgraded to wp 2.7 yesterday.

I actually got a fatal error myself. The plugin does activate, and seems to be working properly. The following is what I get:

Plugin could not be activated because it triggered a fatal error:

Fatal error: Cannot redeclare wp_dtree_load_javascripts() (previously declared in /xxx/xxx/xxx/xxx/xxx/wp-content/plugins/wp-dtree-30/wp-dtree.php:113) in /xxx/xxx/xxx/xxx/xxx/wp-content/plugins/wp-dtree-30/wp-dtree.php on line 112

An alternative, probably better, is replacing the original function with:

function the_meta() {
	global $id;

	if ( $keys = get_post_custom_keys() ) {
		foreach ( $keys as $key ) {
			$keyt = trim($key);
			if ( '_' == $keyt{0} )
				continue;
			echo "<ul class='post-meta'>\n";
			$values = array_map('trim', get_post_custom_values($key));
			$value = implode($values,', ');
			echo "<li><span class='post-meta-key'>$key:</span> $value</li>\n";
			echo "</ul>\n";
		}
	}
}

The only ‘disadvantage’ is that it will generate an unordered list for each custom field, populated with exactly one list item.

I ‘solved’ it like this:

In post-template.php, around line 216, you’ll find:

function the_meta() {
	global $id;

	if ( $keys = get_post_custom_keys() ) {
		echo "<ul class='post-meta'>\n";
		foreach ( $keys as $key ) {
			$keyt = trim($key);
			if ( '_' == $keyt{0} )
				continue;
			$values = array_map('trim', get_post_custom_values($key));
			$value = implode($values,', ');
			echo "<li><span class='post-meta-key'>$key:</span> $value</li>\n";
		}
		echo "</ul>\n";
	}
}

Now change that to:

function the_meta() {
	global $id;

	if ( $keys = get_post_custom_keys() ) {
		echo "<ul class='post-meta'>\n";
		foreach ( $keys as $key ) {
			$keyt = trim($key);
			if ( '_' == $keyt{0} )
				continue;
			$values = array_map('trim', get_post_custom_values($key));
			$value = implode($values,', ');
			echo "<li><span class='post-meta-key'>$key:</span> $value</li>\n";
		}
		echo "<li>\n";
		echo "</li>\n";
		echo "</ul>\n";
	}
}

and it spits out an empty list item if you don’t use custom fields in that entry, which apparently doesn’t break validation.

I can report I have the same problem. “_pingme” isn’t in the drop down menu for custom fields though. I do have “_wp_page_template” there, which I suppose shouldn’t be visible either. I use version 2.0.2, with a couple of plugins that didn’t cause any trouble before, and where indicated as compatible.

It is annoying to me even though some told me the “_encloseme: 1, 1” showing on my blog, looks kind of geeky.

I strongly dislike target=”_blank” …

Just in case, I’ve submitted this to the bugtracker:

https://mosquito.www.ads-software.com/view.php?id=864