kirkpatrick

The “development version” that is available at downloads.wordpress is only 1.7.2, not 1.8a2. If you have fixed this in 1.8a2, maybe you should take the fix back to 1.7.3 as stable. It is a devastating bug.

The narrow WYSIWYG editor column problem occurs, in FEE 1.7.2, on FF, Opera, Chrome, on sites with very different setups and themes, both live (Linux) and locally served (Windows). It is fairly new (a few weeks?), doesn’t seem connected with any plugin change, and occurs with all other plugins deactivated.

It occurs regardless of FEE configuration — even if only checked “edit post content” (which avoids your multiple-id error — which really should be corrected, please).

For some reason FEE inserts into some divs completely unnecessary inline styles of width:nnn, where nnn doesn’t make any obvious sense, but is much less than full (and differs for me on different sites). By “completely unnecessary”, I mean that if I remove them (using FireBug magic), the display becomes correct.

Let’s get this fixed — I’ll start reading code now.

Kim Kirkpatrick

When you say “Here is what I have in my html”, I take it you mean that you have a mailto link with the email as the “name”, as per
<a href="mailto:[email protected]">[email protected]</a>

If this is what you want, just type [email protected] — no html tags. (It’s supposed to be easy!)

You don’t say what is the text source that emObA is converting, so I have no idea which branch of the program is being called, or what other difficulties might be activated.

Also, you don’t describe the multiple-server arrangement of files. However, I rather doubt your guess as to what the problem is. In emoba.php, the relevant code is
<img src="' . plugin_dir_url(__FILE__) . 'at-glyph.gif" alt="at" class="emoba-glyph" />'
According to the source documentation for plugin_dir_url(param),

param: string $file The filename of the plugin (__FILE__)
return: string the URL path of the directory that contains the plugin

Note that the code does not involve plugin_dir_path(__FILE__), which would return the “filesystem path of the directory that contains the plugin” — only this would return a value “based on the filesystem path instead of the server path”

I think the problem lies elsewhere, or plugin_dir_url (rather, plugins_url() ) doesn’t work for your multiple-server setup.

I suggest that to fix this for yourself, you hard-code the appropriate path into lines 63 and 64 of emoba.php (and watch out for this when upgrading). But if you don’t want to do this, then you would need to review the coding of plugins_url() to see if something can be done to make it work for your setup, and let me know.

Well, I didn’t realize when I wrote 1.3 that plugin_dir_url was not introduced in WP until v2.8.

I believe I will deal with this the lazy developer’s way: emObA 1.3 requires WP2.8.

If you don’t want to upgrade WP and you know a tiny bit of PHP, you could patch emoba.php around line 51, in the code

/****
Place the css in the head:
****/
function emoba_includes(){
  wp_enqueue_style( 'emoba_style', plugin_dir_url(__FILE__) . 'emoba_style.css');
}
add_action('init','emoba_includes');

by replacing plugin_dir_url() with (I think — not sure of the final slash)

'/wp_content/plugins/emoba_dir/'
where emoba_dir is the name of the folder emoba is in.

Sorry for the delay in responding.

I did not try to create the logic necessary to detect an email “name” in an email link. It is fairly tricky, and exactly the result that i think you desire would occur if you just don’t put the html link in.

That is, what you expect emObA to do to <a href="mailto:[email protected]">[email protected]</a> you will get by simplifying to [email protected].

If you want an email link with a “name” = the email, just type in the email. Is there a problem with doing this?

This problem is due to a bug in older versions of PHP (2.8.6 and earlier, if not updated), which prevents regex named subpatterns from being used in preg_replace_callback — something I used in emObA 1.2.

I have uploaded version 1.3 (“other versions”) — it’s not yet the stable version. Perhaps you could try it out to see if (as I am pretty sure) it will solve your problem.

If it does, I’d appreciate knowing, and also appreciate it if you would close this issue. Thanks

Works in 2.9 without just fine.

Won’t work in sidebar as it stands (not hooked). Sidebar is usually somewhat static and not usually modified by users other than admin. I suggest setting up the email, and bring it up in a browser, copy/paste the page source to the sidebar php.

But don’t know why it isn’t working in your posts; it is hooked to posts as well as pages. When you say “email addresses as plain HTML text”, I don’t understand — email addresses are just text, HTML or otherwise (they don’t involve < or > ). A mailto link must be HTML, though.

And when you say the output as “the same plain HTML text”, do you mean you see the html itself? That sounds like you put it in using the wrong editor — the visual editor.

No, Flexipages is irrelevant.

I tested thus: Fresh 2.9 install. Got FEE via Add New. Copied test.php into plugins, activated it. Results:

With FEE active, on an actual page (eg, About in the default install), a 2 appears at the top — the page ID.

With FEE inactive, the top of the page has “stdClass Object ( [ID] => 2 [post_author] => 1…” printed — the usual $page object.

What is confusing, and what I didn’t note until I tried this fresh install test, is that it fails on standard pages, but not on posts, archives, or the front page.

I doubt it’s a template problem; the templates of the theme I originally discovered this on are pretty non-standard, but still they behave the same way regarding pages vs other posts.

Note — All this with Flexipages absent.

I doubt I can be of much further help — it took me most of a full day to isolate the problem to FEE and the $page variable. FEE is too complex for me to debug, given I haven’t a clue how this is happening. So I’ll leave it to you, with my best wishes for quick work.

Happy holidays — and thanks for this very useful plugin. It’s essential for my page-oriented CMS group-user sites.

I can’t understand your request. You don’t want to use intensedebate, but you want something “similar” to it?
I would need to know why you don’t just use intensedebate itself, and what about it you do like (what part you want “similar”).
Perhaps with these details someone could help.

Exactly what do you mean by “bare email addresses”? In pages, posts, or comments? Does this happen if you change to the default theme?

If you type in [email protected] (what I would call a “bare” address) you should see a-b-cc as a mailto: link. I’ve just reinstalled 1.2 from WordPress plugin repository, and it works in various themes.

You might look at the source of your page as it posts, see what appears in the emoba span. And use developer tools in your browser to look at the link — is there anything between <a ...> and </a>? Because whatever is there is what you should see, and it seems to have “vanished”. Perhaps this would give you clues you could tell me about.

I just reinstalled emObA 1.2 directly from WordPress plugin repository, and tried it under the classic, default, and my particular theme. The three forms, [email protected], [name] [email protected], and (in html) <a href="mailto:[email protected]">link</a>, all work without problem for me in posts and in comments.

The problem you are describing was happening in v1.0 in comments (only). Is it possible your version changes didn’t take place?

I need more info on just what you are doing — what kind of email format are you inputting, does it happen if you use the default theme, are you using plugins that themselves modify emails?

I’ve posted on the plugin site 1.2beta, which fixes the duplicate-email problem (now identical duplicates of emails are all treated correctly).

@randa

It works now! Get Version 1.1 from www.remarpro.com or from the plugin site.

Thanks for your report. (Don’t quite understand how this got by me. Evidently I didn’t test bare emails in comments, or notice that the behavior I saw was no-JavaScript behavior even when JavaScript was on. DUH! Apologies to all.)

Because of the seriousness of this problem, this was the only bug fix made.

Note (just to let you know that I’m aware of it):
Another problem, which I should have cleared up within 24 (hours, not days, I hope), is that when there are duplicated emails, only the first is handled properly.