jrawle

It’s actually quite easy to fetch the extended tweets. I simply added the extra parameter
$parameters['tweet_mode'] = 'extended'
to the feed request settings.

Then in the “display” method, you need $tweet->full_text instead of $tweet->text

@thirzah, thanks for this fix, it saves me the trouble of figuring it out for myself.

I was going to report this as a bug, but found this when I was checking for existing reports.

I hope it can be fixed eventually, but I do appreciate why a general fix for any number of @replies requires quite a few changes to the way the plugin works.

OK, so I have managed to get my “real” site working. However, I couldn’t do it “properly”, and I feel this may indicate an issue with the way shared servers used by some hosting companies are set up. This may explain why so many users are reporting problems in this forum.

First I had to create a new Twitter application and Authorize my account for use on my local server, as I did before. This worked correctly just as it did last time.

As my public server still wouldn’t Authorize my Twitter account, I viewed the database tables for my local server and copied the ‘twp’ and ‘twp-authed-users’ rows to my live server. Then all I did was refresh the settings page and it showed my Twitter account as authorized.

I realise this isn’t much help to most people unless they have an alternate server and the time to install WordPress on it. However, I feel it shows the plugin works fine except for the Authorize stage which has problems on particular server setups. If the author could suggest the best way to debug the communication between the WordPress server and Twiter I’d be happy to help, as I understand it’s difficult for him to fix this when it works correctly for him.

For the moment, one difference between the two servers that springs to mind is that the “live” server runs PHP via fastcgi, while my local server runs it as an Apache module. Otherwise they are set up quite similarly.

Thanks for posting a fix for this. I hope it’ll be fixed in the next version of the plugin (I specifically wanted a plugin I didn’t have to hack to make it work!)

This is definitely to do with the version of PHP. I always develop and test my site using a local webserver on my workstation, but I have PHP 5.1.6, which seemed fine, whereas my host uses PHP 4.4.4, and that had the problem with the datestamp.

I can’t see it give a PHP version as a requirement, and I note that the plugins website allows users to report whether it’s working by WordPress version, but not by PHP version.

I posted a week or so about people’s URLs not appearing in their profiles. It seemed this was for users who don’t post often enough. Now it seems some users don’t have profiles at all!

Not letting other people read profiles can be considered an anti-spam measure, but logged-in users should be able to see their own profile, otherwise it makes the forum very awkward and inconvenient to use.

The message that is returned when attempting to view a new user’s profile is also incorrect. It says “User not found”. It should say, “User’s profile inaccessible” or something. Otherwise it suggests the user has been deleted. I came back to a post where I was helping a user earlier in the week, and I thought the user had deleted his account. I went to the trouble of e-mailing him with the solution in case he didn’t read the post – simply because of the misleading 404 page.

Maybe this was an emergency measure, but it really needs to be tidied up now to make the forum more usable!

Apologies for the absence, I haven’t visited this site for a few days.

You need to find the code that outputs the text you want to remove, i.e. the category, number of comments, etc. As I said, this isn’t the header, it’s usually called the postmetadata in WordPress parlance.

You need to surround the entire section you want to remove with my code. I reckon this is a good place to start:

<?php $show_meta=get_post_custom_values('show_meta');
if(trim($show_meta[0])!="no") { ?>

<p class="postmetadata">
<!-- from <?php the_author() ?> -->
Category
<span class="catr">
<?php the_category(', ') ?>
</span> :
<?php edit_post_link('Edit', '<span class="editr">', ' : </span>'); ?>
<span class="commr">
<?php comments_popup_link('no comments ?', '1 comment ?', '% comments ?'); ?>
</span></p>

<?php } ?>

Note that I’ve changed the name of the custom field to show_meta to better reflect what it does.

Hope that helps!

Incidentally, this isn’t really the “header”, which in WordPress usually means everything that goes at the top of every page. But I’ll stick with your terminology for this thread!

You can use a custom field, for example, you can call it show_header. If you set the values of “show_header” to “no” for a post, you want it to miss off the header.

You need to add the following to your theme, around the code that shows the header. This will probably be in index.php, single.php, and maybe other files, in your theme’s directory.

<?php $show_header=get_post_custom_values('show_header'); if(trim($show_header[0])!="no") { ?>

... code to display the "header" here ...

<?php } ?>

That should do it! Be sure to keep a backup copy of your theme in case you break it!

Under what circumstances do you want to remove it? When comments are disabled? Or is it that some content would better be placed on a “Page”, which won’t have that line?

If you want more precise control, you can use a custom field, and it’ll require a small modification to your theme.

Let us know what you are trying to do!

Thanks for the plugin. That method of disabling autosave is particularly welcome as it’s better than setting the autosave interval to a large number!

I’m not quite sure what you mean. You don’t use Akismet? So how did you mark the comments as spam? Manually or by blacklisting?

If you have 10 000 spam comments in the database and want to delete them, have a look at CJD Spam Nuker:
https://chrisjdavis.org/cjd-spam-nuker

I used to use this before I started using Akismet, but I can’t vouch for it working under the latest WP versions.

I recommend Akismet anyway, it’s actually very good.

Well, I’ve made a few posts in the last few days (mainly about revisions, as you know!) and lo and behold, my site has just become linked!

Autosaves may not save “revisions” as such. But when you edit an existing post, autosaves are stored as a duplicate copy of the post, one for each post that you’ve edited. You can prevent this by increasing the time before an autosave to something very large:

define(’AUTOSAVE_INTERVAL’, 600000);

It’s a bit messy, I know, but it does stop it. The only automatic save is then the one that occurs a few seconds after starting a new post. That does create a row in the posts table, but it’ll be the row that becomes the final post, rather than an additional one. This initial save is still a nuisance if you open the editor but then decide you don’t want to write after all.

You need some sort of permalink that does not include the post ID, because in their wisdom, the developers have introduced revision control which means post IDs no longer remain constant if you edit the post, and post IDs can very quickly become large.

Note that you can set the post “slug” yourself, you don’t need to use the long ones WordPress suggests automatically. You can take just one or two key words from the title to produce a shorter permalink.

So if you blog about “Why revision control in WordPress is a real pain” you can use a post slug such as “wordpress-revisions”

For your bilingual blog, one option would be to set the slug to one language or the other.

As well as space, the other issue is the way post IDs very quickly become large. This is the case even if a plugin is used to delete all the revision and autosave posts from the database.

I’ve noticed that post IDs are effectively hidden in the admin screen from 2.5 onwards. However, they are still used by many people. Some people may use them in permalinks to give short URLs. Their URLs may now have jumped from example.com/1, example.com/2 to example.com/25 then example.com/112.

Some plugins also make use of IDs.

It also seems that autosaves result in an additional “post” in the table that isn’t deleted even when editing is complete.

Really it might have been better if revisions and autosaves had been contained in a separate table so that they didn’t interfere with the way posts are contained in the database.

It seems ridiculous that “those in charge” are refusing to add an option – just one small checkbox – for this because it makes WordPress “cluttered and confusing”. Yet they were perfectly happy to add in a hugely confusing, obtrusive and wide-reaching feature such as revision control to WordPress in the first place.

If you don’t like this feature and would like an option added, please go to WordPress Trac and add your support to ticket #7360.