heriz

I can’t see there being a solution though – as future posts was always meant to be for scheduling the publish date, not just giving a post a future date.

And I’m done with hacking core files – it’s such a bad idea.

I think I’m going to use tags + custom fields for this, and forget using the post date for the event date.

The hack is here:

https://www.ads-software.com/support/topic/141099

BUT this was for an old version of WP, and as far as I can tell it can’t be dropped into 2.8.4’s query.php.

For those who know their code, I think line 2127 seems to be the area needed to be hacked, but I don’t know my code so that could be rubbish.

} elseif ( !$this->is_singular ) {
			$where .= " AND ($wpdb->posts.post_status = 'publish'";

			if ( is_admin() )
				$where .= " OR $wpdb->posts.post_status = 'future' OR $wpdb->posts.post_status = 'draft' OR $wpdb->posts.post_status = 'pending'";

			if ( is_user_logged_in() ) {
				$where .= current_user_can( "read_private_{$post_type}s" ) ? " OR $wpdb->posts.post_status = 'private'" : " OR $wpdb->posts.post_author = $user_ID AND $wpdb->posts.post_status = 'private'";
			}

What to do with this, I’ve no idea.

However, when the hack is in place the future posts mechanism used as an events listing is incredibly elegant (bar the problem of RSS). To simply have a future date published for viewing, which automatically files into ‘past events’ once the date has passed, is so useful.

I do use this for one of my sites but since the upgrade I’m going to have to find another option. Unfortunately I exhausted them when resorting to this hack so I’m not sure how I’m going to find a solution.

Any help or pointers on this would be hugely appreciated. I think it may be something that’d interest a lot of other people too.

Sorry, should’ve searched a bit better:

https://www.ads-software.com/support/topic/225842?replies=2

No-one?

The _blank option doesn’t work in Safari…

https://www.ads-software.com/support/topic/305060

NB, this could be achieved using the ‘sticky’ or ‘announcement’ features, but I have an events section which conflicts with these, for some reason I don’t entirely understand.

The idea is that if we want an important post to remain on the front page for longer, while continuing to post – we simply place it in the ‘featured’ category (AS WELL AS the normal category) for as long as needed.

I may be describing a well known technique, but I’ve not seen it mentioned before.

After a bit of testing, it seems it is still compatible, but Lightbox conflicts with it.

Time to find a lightbox alternative then.

Swimy, I gave up – I agree with Moshu, it’s unnecessarily confusing. Using a next page function with multiple categories is bound to cause confusion.

I used tags instead, which works fine.

No-one? If not I just won’t create the list dynamically I guess.

As usual, something about posting on this forum conjures up the solution without anyone actually saying anything

I just needed to define the left position of the absolute-positioned div.

Idiot

In fact it’s weirder than that – the navigation div starts wherever the last thumbnail ends – but it’s not following on inline

So I guess it could be a clearing issue?

Either way it doesn’t look related to WordPress enough to warrant being here. Sorry. I’ll have to look elsewhere for an IE fix of this sort.

I didn’t get this the first time round.

Warmbeer… thank you so much!

I suppose I’ll just have to use a Splash page calling a splash template with the flash intro included in that.

This doesn’t work, or at least for me. Carrington uses the page.php to call different templates from within the page directory – so adding a template to the page directory and calling that should work…

Problem isn’t calling the page template, it’s calling a specific header from within that template. I think this is because of the directory structure.

I’ve tried as many variations of the instructions in the README file but I just can’t work it out.

Anyone?

Ok – I seem to have fixed it.

I went into my database to look at the metadata in a bit more detail. In the postmeta table, I noticed there were reams and reams of entries with post_id reference ‘0’. This suggested to me that it was actually these posts’ meta (rather than ALL posts’ meta) that were being pulled into the custom fields because they had no specific post id, so they acted like a wildcard.

Soooo… I deleted them all by hand. An absolute ball-ache, but as I’m new to all this, it was the only way (a search query threw up nothing).

After checking that there were no ‘0’ post_id’d entries left, I backed it all up again, checked my site to see if any of the custom field-related items were affected (they weren’t), re-added the code Gary took out of edit-form-advanced.php and checked the Write Post once again. No renegade custom fields. Checked the Manage Posts again, and the custom fields were back.

I don’t want people to see this as ‘the answer’ because I really am a novice at databases and wouldn’t want to put false information out there. But this did work for me, and I think its quite important because using Gary’s hack will mean that a wrongly-entered custom field will disappear into the database, and potentially cause problems if you can’t edit it from the post page itself.

I hope this is helpful, or at least interesting to someone!