Few modifications

Eh….. I mentioned before I didn’t do that on purpose. I’ll think about it. More people use the widget sidebar for login and registration there, so they can control things. No promises.

another example, when the user click on the activation link on the email, they go on a page which say
you account is activated, you can sign in here
and the link goes to wp-login ??

sorry but you made some mistakes.
a callback for a shortcode should return the text, and not echoing it.
jmm_shortcode_func
does not return the text.

i think you should replace it to :

function jmm_shortcode_func( $atts, $content = null ) {

    add_action( 'wp_head', 'wp_no_robots' );
    $wp_query->is_404 = false;
	ob_start();
   include_once( PLUGIN_DIR. '/lib/signuppage.php');
	return ob_get_clean();
}

also, on signup page, you use
do_action( 'after_signup_form' );
but you forgot the action “before_signup_form”
and that messup my theme ??

oh, and another problem,
you copied this:
<div id="content" class="widecolumn">
to the signup page
but wp-signup.php is a PAGE, while “signuppage.php” is a CONTENT, displayed on some part of the page.

Therefore, there are two div with id “content”, because yours shouldn’t be used
i think you should also remove the class widecolumn (or better, remove that div)

PLEASE pleas please please please learn to use the code tags, eh? It’s a nightmare reading code when you don’t.

What theme are you using?

another example, when the user click on the activation link on the email, they go on a page which say
you account is activated, you can sign in here
and the link goes to wp-login ??

How is that wrong? The email SHOULD send them to where they login.

ETA: Why ob_start/close?

In general, it’s a bad idea to use output buffering unless there’s no other way to do it. In the case of the given code, and so far as I can tell, there are no errors with the way it is now.

i’m using pagelines as theme
i’ve added do_action( ‘before_signup_form’ ); and removed the div with the id content in your plugin and it worked.
About the ob start, like i said, a shortcode hook should return the text and not “echo” it, it can lead to visual problems with some configurations

I agree the do_action needs to be in there, that’s an oversight.

I question your theme, because the div with content is exactly what the actual signup page does, and it works just fine on the default themes, and any other I’ve tested with so I wonder if there’s something special going on that causes problems.

I get the return vs echo, I don’t get why ob_start. Again, output buffering bad ??

yes but the signup page is a page, i mean nothing else than this page will be executed. It contains the template of the whole page.

But with your shortcode, the template of the page will be defined and your “singuppage.php” will be placed inside that template

that’s why you didn’t included, by example, the :
<?php get_footer(); ?>
which you can found inside wp-singup

the reason of the ob_start, it’s because in your signup page (included inside the callback of the shortcode), you do a lot of echo.
But, like i said, in a callback of a shortcode, you should RETURN a string containing the data you want to display, and not “echo” it !
while it may works in most of the configurations, some times i’ve seen random problems caused by this kind of mistake ??

I’d appreciate actual details on the ‘random problems.’

Also what specs is the server where you tested this? Versions of PHP etc ??

i don’t remember the exacts problems, i think it was with filters, with the content displaying in the wrong place, because the echo was done “too early”, but filters works a little differently, because a filter can have multiple callbacks, so if you echo the data instead of returning it, the second callback will not have access to the data

PHP 5.3.3-7+squeeze15
Apache/2.2.16
w3 total cache

don’t forget to thank me in the changelog ??

thanks for the kudos ??

what do you think about the removing of that:
<div id=”content” class=”widecolumn”>

and the “return” instead of echo ?

I’m thinking about it (and I haven’t finished that release, since I’m busy with the work that pays me ?? )

The problem is that if you don’t have the id=content, there are issues with other themes. I want a more elegant way of handling that.

Also if I COULD switch to return, I would, but I don’t want to rejigger the entire page that much. Too much work in the long run for not enough benefit. It introduces too much human error if I go and re-write the functional login page. I’ve already made enough changes.

I have not tested the ob flushes fully (I don’t know if it would cause other hooks from other plugins to break). Since the reason one would put it there would be to prevent errors, and there are none happening that I can find with this implementation, I’m leaning towards ‘It’s not broken, don’t screw around with it.’

BTW, I have other posts where people reported that using the default WP translation did NOT work, so I’m sticking with using my own.

but there WILL be a id=content on the page
if this div is absent, it means that the theme isn’t displaying it.
But with your code, we have two div with the same id, and the layout is abnormal because of the class

okay for the translation, i will then provide a translation file for french

do you have any news? do you fixed the problem with the id content ?