jfbprivate

Thanks for getting back.

I wouldn’t necessarily call it bad practice as it is also the only way to do it in WordPress, and publishers actually do use it that way. Just a random example:

'Sad' Keanu Reeves Memes Aren't Accurate, Says <em>John Wick</em> Director: He's an 'Incredibly Positive Guy' (Exclusive)

Looking up albums in Wikipedia you’ll notice that they’re italicized using <i>. Example:

<i>Songs in the Key of Life</i>

As for the CSS method: Of course I can style all page titles using CSS, but not all page titles are supposed to be italicized — only actual titles (see above example). So that’s not a solution either as that method would affect all titles.

Again, I can work around most as described in my earlier post, but in tables, page titles that include HTML are being ignored and won’t generate a wiki link which is a knock-out criterion.

So, if that can’t be fixed, I will have to roll back and live with the fact I won’t be able to display titles the correct way.

I hope this clarifies it.

Thank you again.

Trying to summarize it one last time:

The actual page title:

<em>This Is a Title</em>

The page link in body copy (using the regular link without HTML will work just fine):

[yadawiki link="This Is a Title"]

The page link in the TOC page (the HTML bit needs to be included or the page won’t be recognized):

[yadawiki link="<em>This Is a Title</em>"]

All index pages will display the italicized page titles correctly.

The issue with tables:

Links to a page with an italicized title (<em>This Is a Title</em>) will not be recognized when placed inside tables. Neither this ([yadawiki link=”This Is a Title”]) nor this ([yadawiki link=”<em>This Is a Title</em>”]) will work.

This is NOT about DISPLAYING them italicized as in your last example. The problem is that they’re not being recognized as pages in tables in the first place.

Not needed, I’m not feeling any frustration, I was only trying to make things as clear as possible.

First of all, thank you again for your time and efforts.? Now let me try to narrow it down—it’s actually not as complicated as it might sound.

<td><em>[yadawiki link="Beaver Builder" show=""]</em></td>

Your example above is working for me too. But that’s not the point. I have a page title that is italicized. Those links are not working anymore when put in a table. I have attached a screenshot to illustrate what I’m talking about. I probably should have done that earlier.

Thanks but that isn’t what I’m talking about at all. I don’t think we’re on the same page here.

I know my way around CSS and how to italicize text. This is about page titles that are italicized using <em> and therefore no longer being recognized as proper Yada Wiki links.

The page title actually is “<em>This Is a Title</em>” appearing like This Is a Title on a page and on index pages.

The problem is that in tables (<table>) they are NOT being recognized as valid links any longer (see my post above).

The other problem is that on the TOC page, the <em> part has to be INSIDE the shortcode to make it work and generate links successfully, like this:

[yadawiki link="<em>This Is a Title</em>"]

Everywhere else in the wiki the following will do (without the <em>):

[yadawiki link="This Is a Title"]

I think if you read my posts again you’d understand. But I will try again and summarize what we have so far:

(1) I need SOME (page) titles to be italicized, which requires HTML, like in the following (please note that I’m referring to actual WordPress page titles here):

<em>This Is a Title</em>

(2) In order to have those titles appear italicized in body copy as well, I can do the following:

<em>[yadawiki link="This Is a Title"]</em>

(3) So far, all is working fine, including on the index pages (All Pages, Categories). The links will work, and even the respective titles will automatically be italicized on those pages. For body copy I use the HTML workaround as described in (2).

(4) Now the problem is, that in tables neither the regular Yada Wiki link ([yadawiki link=”This Is a Title”]) nor the workaround needed for the TOC page ([yadawiki link=”<em>This Is a Title</em>”]) will work.

Bottom line: I could live with the workaround for the TOC, adding <em> inside the shortcode (even if inconvenient), but if italicized WordPress page titles won’t be recognized in tables at all, then that’d be a knock-out criterion and I would have to relinquish that concept. I admit it’d be a pity, especially for a wiki since that’s how title are being formatted in this context.

That’s why I was asking whether or not you know why wiki links in TOC and tables behave differently than in the rest of the wiki and if this is something that can be fixed.

Thank you.

When the actual page title is italicized using <em> I also want the title to be italicized everywhere, otherwise I wouldn’t format it that way.

So far I have figured that I need to add the <em> OUTSIDE of the shortcode to italicize titles in the body copy.

I also found out that index pages will automatically recognize and honor the italicization and display the links accordingly (working links with italicized titles), unlike the TOC page which acts differently. There, I would have to include the <em> INSIDE the shortcode in order for the TOC page to recognize those titles in the first place.

Lastly, in tables, none of the workarounds will do, as wiki pages that have an <em> in their title won’t be recognized at all.

Does that clear things up?

Unlike the index page items which are wrapped in <div>, maybe this behavior is caused by list items since the TOC links are wrapped in <ul> and <li>. Just an idea.

I also noticed that in tables, italicized page titles won’t work or be recognized as links at all — not even with the help of the workaround that does the trick for the TOC.

None of the following will be recognized as links:

<td><em>[yadawiki link="This Is a Title"]</em></td>

<td><em>[yadawiki link="<em>This Is a Title</em>"]</em></td>

<td>[yadawiki link="This Is a Title"]</td>

<td>[yadawiki link="<em>This Is a Title</em>"]</td>

Unless you can figure out these two issues, I will probably have to go back to normal page titles and live with that for now.

Yes and no, because the links aren’t being generated. Instead I get a span with .wikilink-no-edit.

It should be a link with .wikilink-published though.

The problem is that, unlike in other areas of the wiki, the TOC page will not accept/ignore the <em> in the page title. So my workaround is to actually include the <em> in the titles of the TOC page.

So instead of [yadawiki link=”This Is a Title”] like for the rest of the wiki, I would have to use [yadawiki link=”<em>This Is a Title</em>”] to make them work. Which is a little confusing and makes it more complicated than necessary because now I will have to remember which titles are italicized.

Is there a way to make title links in the TOC work like everywhere else, not needing to include the <em> in the title?

Thanks again.

Hi,

Any news on this?

Thank you.

Hi,

Any news on this?

Thank you.

“Ignore all query parameters” would actually do the opposite of what I need it to do.

Anyway, I got it working now. “Exact match in any order” was the correct setting, but I had to uncheck the “Ignore Slash” option. I had tried that earlier and it didn’t work then. Might have been a caching issue.

Thank you.

Thanks for your response and apologies for the late reply.

I think I can live with that. I noticed that even Wikipedia has the quotes outside the title link.

There is one last issue however. The page titles for titles that need to be italicized are in the following format which works well all throughout WordPress:

<em>New Title</em>

This will display them correctly on both the actual pages and index pages of Yada Wiki, TOC being the exception.

The TOC page somehow doesn’t recognize them as existing pages. Could that be caused by the HTML in the titles? Interestingly that is not an issue anywhere else. The HTML bits are being ignored on all other pages.

I’ve tried the following but the links show up as not-yet-existing pages:

[yadawiki link="New Title" show=""]

[yadawiki link="<em>New Title</em>" show=""]

Any idea what might be causing this or why the TOC page is behaving differently from the rest of the wiki?

Thanks again!

Thanks for the quick response.

The documentation doesn’t really mention the case. I have tried all these options but they’re not working for me.

I quote, “For example, if your source URL is /my-old-post and your target URL is /my-new-post, and the user requests /my-old-post?tracking=1 then the redirected URL will be /my-new-post?tracking=1“

That is exactly what I don’t want.

I need /checkout/ to redirect to /account/. And /checkout/ only. For example, I need /checkout/?item=1 to be excluded from the rule.

However, in your example above this would redirect to /account/?item=1 instead, which is what I don’t want since it would break the link.

The idea is that users are not supposed to access /checkout/ itself. The same is true for /confirmation/. These pages don’t make sense without their respective query parameters.

Thanks again.

• This reply was modified 1 month ago by jfbprivate.

PS: I forgot to mention that I was referring to the TOC page and other lists.

Setting up an index table via [yadawiki-index type=”pages” columns=”4″], on the other hand, all pages with titles in the form of ‘<em>This Is a Title</em>’ will both display italicized and work as links correctly.

Thanks for the quick response.

This is a working solution using HTML:

[yadawiki link="This Is a Title" show=""This Is a Title""]

Now, similarly to using quotation marks for some titles, I’ll have to italicize others. The problem with that is that <em> seems to be ignored in both ‘link’ and ‘show.’

Wrapping the entire shortcode in <em> would work:

<em>[yadawiki link="This Is a Title" show=""]</em>

However, I also need the page title to be italicized, which means that the Yada link would no longer be “This Is a Title” but “<em>This Is a Title</em>” since that’s what the actual page title would be now. That brings up another issue because Yada Wiki won’t accept <em> as part of a link and will turn it into a ‘wikilink-no-edit.’

If the plugin would accept HTML in page titles, I could make it work like in the following:

[yadawiki link="<em>This Is a Title</em>" show=""]

As mentioned above, I have also tried using <em> in ‘show’ but that is being ignored too:

[yadawiki link="This Is a Title" show="<em>This Is a Title</em>"]

In order to make it work like in the above example, the plugin should IGNORE the HTML in the page title (‘link’) and ACCEPT the HTML in the ‘show’ part. That would probably be the most straightforward solution. I’m actually surprised that it does accept ‘&quot;’ but not <em>.

I feel like especially a wiki should be capable of styling titles properly. Am I missing something?

Thanks again for looking into this!

Hi,

Replacing those lines seems to have fixed that particular issue.

I’ve come across some other (related) problems however.

================

Instead of what is set in the plugin I’m getting the default BuddyBoss/BuddyPress error messages for the following scenarios:

Username too short:
[1 character] = “Username must be at least 3 characters” (BuddyBoss)
[2 characters] = “Username must be at least 3 characters” (BuddyBoss)
[3 characters] = “Username must be at least 5 characters.” (plugin)
[4 characters] = “Username must be at least 5 characters.” (plugin)

Username too long:
[16 characters] = “Username may not be longer than 15 characters.” (plugin)
[32 characters] = “Username may not be longer than 15 characters.” (plugin)
[33 characters] = “Username must be shorter than 32 characters.” (BuddyBoss)
[34 characters] = “Username must be shorter than 32 characters.” (BuddyBoss)

Username empty:
[0 characters] = “This is a required field.” (BuddyBoss)

================

Here are more but I realized that there are no options for name and empty password fields in the plugin, even though that would actually be a useful addition.

Name too long:
[33 characters] = “Name must be shorter than 32 characters.” (BuddyBoss)
[34 characters] = “Name must be shorter than 32 characters.” (BuddyBoss)

Name empty:
[0 characters] = “This is a required field.” (BuddyBoss)

Password empty:
[0 characters] = “Please make sure to enter your password.” (BuddyBoss)
[0 characters] = “Please make sure to enter your password twice.” (BuddyBoss)

================

At least in the case of BuddyBoss/BuddyPress the plugin doesn’t seem to successfully overwrite the default error messages.

In fact only the email field seems to be working correctly for both empty and existing values.

I would very much appreciate if you could look into this. I can’t be the only one having these issues.

Thank you!