Leto

I only had bbPress forums installed, not buddypress.

I have fixed most of the styling issues myself, and it did not take many lines of css to do it, but it did cost me some time and head-scratching. I had no real interest in css and would have preferred something that worked out of the box.

It is not as though twentyfifteen is an obscure WordPress theme. It is the default theme, after all, so most plugins should aim to work without requiring that their users learn css and puzzle through styling issues.

I can’t remember all the issues I faced in getting bbPress to work with twentyfifteen, but it certainly did not look any good without tweaking the css. Replies ran outside of the provided frame, for instance, cutting off the right-hand end of most lines. Many other things like headings had awkward spacing so that words ran into each other. I would challenge the bbPress team to install bbPress on a standard twentyfifteen-using site, and without tweaking the css, give us a link so we can see the results and experiment.

If you just want to have text pop up when you hover over an image, use normal html instead of a plugin. The “title” attribute of an image gets displayed as a pop-up.

For instance, see here:

https://stackoverflow.com/questions/12105214/display-text-on-mouseover-for-image-in-html

Having played around, this problem only appears when I use formatted/styled hover text via qtip The qtip does not seem to be activated on the home page, which contains multiple posts, but it is activated on pages and single posts.

I suspect you’ll need to find the relevant filter for the text output of the page builder plugin, and then add the text hover filter to that. That can be quite tricky if you are not a programer.

A very gracious reply. Best of luck with developing it further. I suggest looking over someone’s shoulder while they try to get it going on the default twentyfifteen theme and see how long it takes them to get it looking decent on both PCs and mobiles.

To be fair, thinking back, it’s possible the moderation was affected by the fact that my dummy users had previously submitted posts. The appearance on mobiles was the main barrier for me.

I agree that a fair bit of css tweaking is needed to make it work in twentyfifteen. I’m in the process of integrating it now. But it can be done.

What were the issues you faced?

Hi there,
I’ve fixed the issue on my site with the following mod to the plugin. The first line below was already there, the next two I added:

$text = ' ' . $text . ' ';
$text = str_replace( '</p>',' </p>', $text);
$text = str_replace( '\n','\n ', $text);

Similar approaches may be needed for specific issues on individual posts, so I will perform more str-replace calls as needed.

It would still be nice to fix this for other users.

I looked at the page source for the end-of-line issue in the forum, and it appears that this is a variation of the <tag> problem.

The relevant bit from the link above…

<p>But fails without the fullstop...<br />
目</p>

I can probably fix it by doing a global replace of all “</p>” with ” “</p>”, and perhaps all something similar with break tags, just prior to the regex test.

I’ve changed back to your original regex expression, I think (Hopefully the commented out version was unchanged.)

The current line reads like this:

$regex = “(?!<.*?)([\s\’\”\.\x98\x99\x9c\x9d\xCB\x9C\xE2\x84\xA2\xC5\x93\xEF\xBF\xBD\(\[\{])($old_text)([\s\’\”\x98\x99\x9c\x9d\xCB\x9C\xE2\x84\xA2\xC5\x93\xEF\xBF\xBD\?\!\.\,\-\+\]\)\}])(?![^<>]*?>)”;

With that line in the plugin, I still don’t get a translation of the eye kanji when it is the last character in a line in my forum. Adding a fullstop fixes the issue, so in most cases it will be fine, and I could always add a space and a dummy tag to the html. The problem is that I can’t expect visitors to remember to do that.

Hi,

Thanks for the feedback. The plugin has been really useful on my site, as you can probably see. I had a go at fixing the tag issue but don’t know enough about regex at this point.

Kanji at the end of a sentence are okay if there is punctuation after the kanji. An example of where it fails is in the discussion thread…

https://kanjisketchpad.com/kanji/kanji-keyword-shortcuts-and-hover-text/

In particular, you can see the comment by me that reads ‘ Testing end of line… ‘ Followed by the kanji for eye.

(By the way, I entered that comment with your other plugin. By combining the two, I can type :eye: which becomes 目, which then acquires the hover in most cases apart from the end of line problem.)

It might depend on which invisible character is used at the end of the line.

I am currently using a modified regex expression from when I tried to fiddle with the plugin myself. I can revert to the original, I think, and will try that now to see if it is something I messed up in trying to tackle the tag issue.

Have you already tried and got no result? If so, make sure the words you want to provide hovers for are separated from html tags by at least a space, and that they do not appear at the end of a line.

Delaying the notice until the user hits ‘Save’ (as you suggest above) would also be unfriendly. Checkboxes that will be ignored should be disabled completely, with a note saying why they are disabled. Don’t leave them there as a trap.

This is very user-unfriendly… Most people won’t expect the default-css option to modify anything except trivial styling, like shadows on so on. To find out that you lose almost everything else in the form because you wanted to keep the styling is just weird… To not tell the user about the clash makes it worse, but it seems wrong even if you do tell the user.

Wish I had known this. The plugin seemed broken to me. I eventually gave up using the form and edited the php directly as it seemed easier than the form – despite the fact that I am not a php programmer. I’ve got it working quite well but will not be able to use any upgrades now.

Firstly, thanks for a very useful plugin…

Secondly, I also have strange auto-indenting going on in my setup. I use Firefox. and WordPress 3.4.1. The problem arises when I edit php files – I’ve not seen it with CSS.

I’m using version 2.1.4 of ACE and 15.0.1 of FF.

When I hit the / key, the insertion point often leaps to the right by about 30-40 characters. When I hit return, I sometimes land on the line below way out off-screen to the right, by about 50-60 characters, and have to delete a whole lot of white space to return to the rest of the code. Other times the return behaves as expected. I haven’t seen a pattern in this behaviour.

For now, I’d just be happy to turn off autoindent completely. I haven’t searched through your code yet for a way to do this, but I’ll try that next if there is no easier way.

Cheers,

Craig.