Alhadis

Uhm. I said it’s the constructor function, which means line 35 of regenerate-thumbnails.php needs to change from this:

// Plugin initialization
function RegenerateThumbnails() {

Into this:

// Plugin initialization
function __construct() {

Make sense? =)

Why was this not documented better? Also, is there a hook that runs after the shortcode’s output the form? (Preferably one that passes the WPCF7 instance as an argument). There was one that ran before it started outputting any mark-up, but I needed to output a script that operated on the form element once it was already in the document tree.

I’ve experienced this as well. Twice. And twice have I had to spend hours in phpMyAdmin manually copy+pasting the correctly serialised data from one database to another.

This is a serious ballbuster, and one I believe shouldn’t be too hard to fix. Any help? D:

I was just searching for this myself. As it turns out, I don’t think WordPress has a native shortcode for including custom menus inside post content.

However, a quick Google search had me stumble into this:

https://www.cozmoslabs.com/2010/06/28/wp_nav_menu-shortcode/

See if it helps. ??

I posted a solution that works when you’re using HTML e-mail:

add_filter("wpcf7_mail_tag_replaced", "suppress_wpcf7_filter");
function suppress_wpcf7_filter($value, $sub = ""){
	$out	=	!empty($sub) ? $sub : $value;
	$out	=	strip_tags($out);
	$out	=	wptexturize($out);
	return $out;
}

And then, BAM, everything was being formatted the way I intended it to.

EDIT: Okay, sweet; just noticed that there was an update available that fixed this wretched problem. Thanks!

Also note that this is NOT the same issue as not having the “WPCF7_AUTOP” constant defined to FALSE; this issue’s a completely different one altogether. The most recent build of the plugin “features” mandatory autop formatting of the submitted post; which means all your field references are going to be broken up line by line, whether you like it or not.

So something like this:

Name: [text* first-name] [text* surname]

Is going to come out looking like this:

Name:
Henry

Anderson

Total pain in the ass.

I posted about this a few weeks ago.

The solution I came up with was a serious hack, but there was no other way around it short of editing the plugin’s core code. Just stick this somewhere in your theme’s functions.php and it should work:

add_filter("wpcf7_mail_tag_replaced", "suppress_wpcf7_filter");
function suppress_wpcf7_filter($value, $sub = ""){
	$out	=	!empty($sub) ? $sub : $value;
	$out	=	strip_tags($out);
	$out	=	wptexturize($out);
	return $out;
}

T-P: “Nesting” simply refers to the hierarchy of a submenu, and how subpages are laid out in a navigation menu. To take a basic example:

Example Of Page Hierarchy ‘Nesting’

Remembering that pages are sorted like a hierarchy, you have one list of pages sorted under another. WordPress outputs the page tree like this (note that I’ve stripped out most of the attributes for clarity):

<ul>
	<li><a title="Home">Home</a></li>
	<li><a title="About">About</a>
		<ul>
			<li><a title="Alpha Breed">Alpha Breed</a>
				<ul>
					<li><a title="Psycroptitude">Psycroptitude</a></li>
				</ul>
			</li>
			<li><a title="Beta Breed">Beta Breed</a></li>
			<li><a title="Human Release Candidate 3.0">Human Release Candidate 3.0</a></li>
			<li><a title="More Than Human">More Than Human</a></li>
		</ul>
	</li>

	<li><a title="Publications">Publications</a></li>
		<li><a title="Stop">Stop</a>
			<ul>
				<li><a title="Supporting">Supporting</a></li>
				<li><a title="Shit">Shit</a>
					<ul>
						<li><a title="Browsers,">Browsers,</a></li>
						<li><a title="The">The</a>
							<ul>
								<li><a title="Future">Future</a></li>
								<li><a title="Is">Is</a></li>
							</ul>
						</li>
						<li><a title="Our">Our</a>
							<ul>
								<li><a title="Choice">Choice</a></li>
							</ul>
						</li>
					</ul>
				</li>
			</ul>
	</li>
</ul>

Which, without formatting of course, would result in a list looking like this.

Now, what you’re all trying to do is make things *pretty* for IE6 users. You’re killing yourselves. The key here is to make the content accessible and navigable for older browsers, and it doesn’t necessarily have to be done in the style of a dropdown menu. Just hide the subpage links in the nav bar so only the top level elements are visible, and have the subpages listed on each particular section when you go to that page. I don’t think IE6 users are going to care about having to make one more click to get to a certain subpage.

“I don’t think my client would be happy telling 15% of the people that visit that they cannot make an appointment because their browser is cr@p”

I’ve explained this situation pretty thoroughly with clients, and they’re mostly willing to have a modest “please upgrade” message on their site for users of older browsers, provided the rest of the site is workable.

Now, don’t get me wrong. I’m not saying leave it garbled for idiot and/or incarcerated IE6 users to stumble through (even if that’s how I’d prefer to leave my personal site). But my approach would be to have more complicated functionality like dropdown menus cut off from older browsers altogether, and just leave the remaining subnavigation accessible in a sidebar in the related subpages (naturally this is going to depend on the design, but I’ve always found gracefully degrading pages to be more helpful than trying to accommodate for IE6 users).

Premise is simple: Somebody wants to continue using an older, crappier browser? Fine. Here’s the site, it’s functional, but I’ve no incentive to make it pretty for you. You want the luxury of having a beautiful Internet, then it isn’t going to be served to you on a silver platter anymore.

Interesting. These stats are collected from a Ukrainian audience, aren’t they?

“That is when I saw how my blog looks in IE5.5, well…”
Interesting you should say that, because tests conducted in the west showed only 6% of people used IE6, and nobody was using IE5.5 (thankfully). It might be that things are that different in Eastern Europe.

But, be realistic: there’s a whole audience of people out there who could likely be coerced to upgrade their browsers if you but provide them a message to do so. That’s what you’ve been doing so, I hope? It doesn’t matter if the message is blatant and in-your-face, or small and subtle, the thing is, these people need to know they can’t just sit around in the putrid dark ages.

Firelord, IE6 is “still out there” because people don’t know they should upgrade. While I commend you for your patience, there’s no sense supporting IE6 unless it’s a government site you’re developing. The people out there who’re still using IE6 are the ones who need to be educated: still an upgrade link and maybe a “Read More” explanation for people who don’t know.

This monstrosity should’ve been wiped out; you’ve every right to put your foot down on anybody ignorant enough to still be using it in this day and age.

Actually, that had no bearing on the ability to store or retrieve meta-data. All it did was add a metabox for users to manage the custom fields themselves.

It’s working now, but… I’m not sure how. For lack of anything better, I explicitly set “query_var” to the post type’s name (“publication”), and I suddenly noticed the metadata was being written to the database properly. Logically, that shouldn’t have had any influence if the default value of “query_var” is to use the post type’s name, but… *shrug* Meh, whatever works… :\

Actually, scratch the bit about it being stored in the Admin menu, I think it had something to do with the form values being held in my browser after submitting the page (because when I left, they’d gone blank again after I returned.)