jpod

So, this is my new work around, which works, sort of (i.e., it displays HTTP URIs, but lacks proper error handling of any sort). I’d really appreciate if you would include a saner solution.

if ( 'https://' == substr( $uri, 0, 7 ) ) {
	$noschema = explode( '/', substr( $uri, 7 ), 2 );
	$host = $noschema[0];
	$path = $noschema[1];

	$socket = fsockopen( $host, 80 );
	if ( $socket ) {
		$http_request = 'GET /' . $path . " HTTP/1.1\n" .
			'Host: ' . $host . "\n" .
			"Connection: close\n\n";
		fwrite( $socket, $http_request );

		while ( ! feof( $socket ) ) {
			$line = fgets( $socket );
			if ( "\n" == $line || "\r\n" == $line ) {
				break;
			}
		}
		while ( ! feof( $socket ) ) {
			print fread( $socket, 8192 );
		}

		fclose( $socket );
	} else {
		trigger_error( 'Could not connect to ' . $host, E_USER_ERROR );
	}
} else {

// Return the file
	ob_clean();
	flush();
	readfile( $uri );
}

Thanks for fixing it :).

Oops, forgot to mark as solved.

Thanks a lot! Much simpler than my solution. And it’s good to know that things will not stop working after the next upgrade :-).

I figured out what is/was going wrong and how to fix it, and it may point to a more general problem.

Zotpress uses the function Zotpress_add_meta_box() (line 93 in zotpress.php) to add its citation features to all registed post types, the relevant loop being:

$post_types=get_post_types('','names');

foreach ($post_types as $post_type )
{
	add_meta_box(
		'ZotpressMetaBox',
		__( 'Zotpress Reference', 'Zotpress_textdomain' ),
		'Zotpress_show_meta_box',
 		$post_type,
		'side'
 	);
}

That is, Zotpress appears to assume that the lay-out of all pages that are used to edit or create posts of a registered post type is more or less the same. However, SendPress does not satisfy that assumption, and there maybe be more plugins or themes out there that don’t.

I don’t know whether there is a standard on how pages that are used to create or edit posts of a registed type in WordPress should look. Maybe you could considerer limiting the above loop to “safe” post types or give users the option to select the post types for which they want to use Zotpress?

I, for the time being, solved my problem by adding the follwoing line to the beginning of the above loop (“sp_newsletters”, “sp_report”, “sptemplates”, and “sendpress_list” are the post types registed by SendPress):

if ( in_array ( $post_type, array ( 'sp_newsletters', 'sp_report', 'sptemplates', 'sendpress_list' ) ) ) continue;

That said, it would be great if that fix wouldn’t be gone with the next update. Could you include something along these lines in the next version? Thanks a lot! Sorry that I didn’t figure that out myself earlier on, but I needed a break.

See also: https://www.ads-software.com/support/topic/create-email-page-garbled-after-installation-of-zotpress

You did! I think I can see what’s going on now. Zotpress makes certain assumptions about how pages that are used to create/edit new posts of any registered post type should look and these assumption do not apply to your “Create Email” page.

My solution is simply to add a line if ( in_array ( $post_type, array ( 'sp_newsletters', 'sp_report', 'sptemplates', 'sendpress_list' ) ) ) continue; to the for loop I’ve posted above. I am not fluent enough in WordPress to know who should fix their plugin, but it seems to me it’s easier for ZotPress to do this and I’ll post in on their forums. Thanks a lot for the reply and sorry for asking before having a more through look at the code; but I needed a break and just couldn’t parse it back then.

Thanks for looking into it, I understand that this isn’t high priority. I also informed Zotpress about the bug, but the Zotpress author hasn’t replied yet.

See:
https://www.ads-software.com/support/topic/zotpress-garbles-admin-pages-of-sendpress

As for who needs to fix what, I’m looking through the code right now, Zotpress uses the following to add its citation features to the posts and pages editors:

/* Adds a box to the main column on the Post and Page edit screens */
    function Zotpress_add_meta_box()
    {
        $post_types=get_post_types('','names');

        foreach ($post_types as $post_type )
        {
            add_meta_box(
                'ZotpressMetaBox',
                __( 'Zotpress Reference', 'Zotpress_textdomain' ),
                'Zotpress_show_meta_box',
                $post_type,
                'side'
            );
        }
    }

That doesn’t seem fishy to me (I’m no WordPress expert though). Did you add a post-type for e-mails?

Thanks.

Sorry, I forgot to check e-mail notification. I think the crash may be related to the class name. I tend to prefix all my classes and variables, but removed the prefix before I posted the code, so there’s likely a namespace conflict. Try renaming the class to MyStaffMember or whatever suits you.

The class is intended to be used to retrieve information about a single staff member for use in the single-staff-member.php, it will not work in other contexts.

What it does is that it allows you to access the data about your staff member (e.g., phone number, email etc.) via class properties, so rather than saying, e.g.:

$custom 	= get_post_custom();
$title 		= $custom["_staff_member_title"][0];

You can say:

$member = new SomePrefix__StaffMember();
$title = $member->title;

Of course, the great thing is that there is no longer a need to define a variable for each field.

There are also some convienience functions, namely, show() and mailto():

show() will print the requested field, inside a <span> tag (or another tag which you can specify as 2nd argument), assigning a DOM (not PHP) class of the form “staff-member-$FIELD” where $FIELD is replaced with the name of the field printed (you can pass a third argument to show() to assign a different DOM class name).

mailto() will simply print out a mailto link with the email address “encrypted” by WordPress’ antispambot() function. If you access the email address via show() or the email property of the StaffMember class, it will not be “encrypted”.

So to give you an example, this is how my single-staff-member.php looks like (note the prefixes).

<?php
/**
 * The Template for displaying staff members
 *
 * See https://www.ads-software.com/support/topic/link-to-staff-member-page
 */

$rockingthevorstand__single_staff_member_obj = new rockingthevorstand__StaffMember();

get_header(); ?>
	<div id="primary" class="site-content">
		<div id="content" role="main">
			<article class="staff-member staff-member-single type-staff-member">
				<header class="entry-header staff-member-header">
					<h1 class="entry-title"><?php echo get_the_title(); ?></h1>
					<?php $rockingthevorstand__single_staff_member_obj->show( "title", "div" ); ?>
				</header>
				<div class="entry-content">
					<?php if(has_post_thumbnail()): ?>
						<div class="staff-member-photo">
							<img class="staff-member-photo" height="180" width="150"
								src="<?php echo wp_get_attachment_url(get_post_thumbnail_id()); ?>"
								alt="<?php echo get_the_title(); ?>" />
						</div>
					<?php endif; ?>
					<div class="staff-member-content">
						<?php if($rockingthevorstand__single_staff_member_obj->email) :?>
							<div class="staff-member-email"><strong>E-Mail:</strong>
								<?php $rockingthevorstand__single_staff_member_obj->mailto(); ?>
							</div>
						<?php endif; ?>
						<?php $rockingthevorstand__single_staff_member_obj->show( "bio", "div" ); ?>
					</div>
				</div>
			</article>
		</div><!-- #content -->
	</div><!-- #primary -->

<?php get_sidebar(); ?>
<?php get_footer(); ?>

Thanks for the patch, but say, could you include it as a feature in future versions? I just patched the plugin for a website I make for a client and I wouldn’t want the next upgrade to break the site. Thanks a lot!

I came up with this simple class to simplify my single-staff-member.php. Maybe it’s useful for somebody else too.

class StaffMember {
	protected $record;
	protected $record_prefix = '_staff_member_';
	protected $class_prefix = 'staff-member-';

	public function __construct() {
		$this->record = get_post_custom();
	}

	public function __get( $field ) {
		return $this->record[ $this->record_prefix . $field ][0];
	}

	public function show( $field, $markup = null, $class = null ) {
		$content = $this->record[ $this->record_prefix . $field ][0];

		if ( !$content ) return;
		if ( !$markup ) $markup = 'span';
		if ( !$class ) $class = $this->class_prefix . $field;

		echo '<' . $markup . ' class="' . $class . '">' . $content . '</' . $markup . '>';
	}

	public function mailto( $class = null ) {
		if ( !$class ) $class = $this->class_prefix . 'email';
		echo '<a href="' . antispambot( $this->email ) . '" class="' . $class . '">' .
			antispambot( $this->email ) . '</a>';
	}
}

Nevermind, I could get rid of “The Events Calendar” after all.

So I spent an entire 10min in development of my wp-slimstat-config.php in vain ;-)? Great to hear. Yes, of course I’d like to test it :). I was about to file another bug at any rate, which may or may not be connected to this one (namely, that all tabs safe for the current stats remain empty), but I’ll just see if the new engine fixes this one at well. Thanks for the fast help!

Thanks, for now I’ll just disable JaveScript Mode. I tried to deactivate all other plugins, but that made no difference (and I can’t tamper with the theme right now, the site just went live).

Thanks a lot, I’ll have a look into why this happens. Right now, it’s just confusing, the other plugins that call date_i18n() seem to work fine. I’ll see whether I can figure out which other plugin is causing the trouble and will let you know.