Split: Blog Multisite section doesn't appear any Blog

[enoversumParticipant]

Well, as I wrote before, you have an option for the CPT on the frontend filter settings, see attachment. I could imagine something quite similar to this for the grouping feature for the frontend, adding up ‘Posts’ and ‘Pages’ since they are no CPTs. You offer to rename it in one place, so it would convenient to have it in another place as well – and it is more vital to me. Having a list of posts with a heading of ‘Post’ [singular] just doesn’t make much sense, plus I might want to completely rename a CPT on the frontend (have this on another site which so far does not use your plugin, but renames a CPT by plugin in the frontend).

Attachments:

You must be logged in to view attached files.

[enoversumParticipant]

Update: Thanks for the comments in the search_content.class.php, it lead me to exactly what I meant – I just replaced

$obj->labels->singular_name

with

$obj->labels->name

so it takes the plural form of my post types. Still an option to rename the output of the %GROUP% variable would be awesome :).

[Ernest MarcinkoKeymaster]

Thanks for the ideas!

I’ll see what I can do about that. If it’s not too complicated, I might slip it into the next bugfixed version today.

Best,
Ernest Marcinko
If you like my products, don't forget to rate them on codecanyon :)

[enoversumParticipant]

Hey Ernest,

that sounds real fine, just lemme know :).

I just looked into 3), the ability to show search results and display something else but the post description, and your solution is more or less going into the right direction, but leaves a desire for modification :D. First of all, it is a bit of a hassle to include each and every possible custom field that should go into that, but mainly because I think we mean two a little different things.

When I cram in every field I want to be able to show into the little box, it just gets overloaded, like

{descriptionfield} {untertitel} {leistungen} {freitext} {textbloecke_0_block_0_text} {textbloecke_1_block_0_text} {textbloecke_2_block_0_text} {textbloecke_3_block_0_text} {textbloecke_1_block_1_text} {textbloecke_2_block_2_text}

However, this is not exactly what I was after. It’s actually two things when I look at it.

A) First and foremost, define in what fields your plugin is searching – this is already possible and happening – and show a snippet with the text highlighted so users can examine what the search result means to them, a little similar to Google search results (they not only take the meta description, but show a snippet of the content in which your search query is being hightlighted). So not every field is showing, only a snippet from the field the search text is found in.

B) This is less stressing, but still useful in that matter – determine on a per-post-type basis what (custom) field should be shown by default. By hitting in every custom field like I just did it produces a highly messy output.
And even if not, if there is no the_content present on my CPT I still get the three dots in the search results. Meaning: If I choose {descriptionfield} {custom_field1} (because on posts, the normal the_content is present, while I need ‘custom_field1’ for my CPT posts), it still displays the three dots when the ‘descriptionfield’ is empty.

By ‘default’ I mean something like searching for a CPT’s name – since the part to be shown would be the title which is there anyway, something like a snippet should still appear below it :).

I hope I am clear of what I mean? If I can be of any help, just let me know ;).

I just came across two minor additional issue when I tried out how highlighting works.

1.) So far it mostly (!) correctly highlights if I search a full word or a word that may be a partial, but ends with my search term. You can try yourself: If you search for ‘ärztliche’ on the main site the partial word is highlighted in ‘hausärztliche‘. However, if you just use ‘ärztlich’ (which is not present as a single word or at the end of a compound word on the site) it still finds the right post, but doesn’t highlight at all. It would be great to have your plugin highlight in any case.
Strange is that it seems to depend on the actual term you are using. When trying the same with ‘Bescheinigungen’ and ‘scheinigungen’, even though the latter is the last part of the word it is not being highlighted.

2.) It is great that you can filter out tags from the description, but this only seems to apply to the standard description fields, not custom fields? When you do a simple search like ‘ach’ on my main project site it shows you that still anchors and images are included, even though they had been instructed to be stripped out in the settings panel (please disregard the small/different font sizes in the search results). Can you look into that as well :)?

All the best

Eno

• This reply was modified 9 years, 4 months ago by  enoversum.

[Ernest MarcinkoKeymaster]

Hi!

3. I understand your point, but for these complex usages are the cases when the filters come in handy. As you can see the backend is already filled with various options and adding something even more complex like a content output builder just doesn’t make sense to me right now.
There is always something more that the user wants, that’s why the backend is overwhelmed with loads of options. At some point I had to say no, because these cases are too special to generalize into the stock version of the product, and 99% of the users won’t even notice it or used it.

So in my opinion you should create a custom function which hooks onto one of the filters and modify the content as you want it to look like. Here is a knowledgebase article on how to do such things: https://wp-dreams.com/knowledge-base/showing-the-post-type-name-in-post-title/

Starting with this simple piece of code you can build up the fields you wanted. It gives you access to the final output array of objects with post ids, final content etc.. So you can easily retrieve the custom fields you need and change the content field to whatever you want.

1. Will test that out on my local server and make corrections 😉

2. It’s excluded on purpose. I switched up a few lines and now it should filter them out even if it’s a custom field content.

Best,
Ernest Marcinko
If you like my products, don't forget to rate them on codecanyon :)

[enoversumParticipant]

Hey Ernest,

thanks again for your effort.

So you would say that showing different fields’ content based on post type is something marginal most users won’t need?

While your hooking solution might let me specify what custom field(s) I want to display on a per-post-type basis, I would still not get only the field displayed that contains the search term – and I think the latter is something that would be interesting to a lot of people. It would be great to have the hook solution to define a default (i.e. search term is in the title or a field not activated to be shown) while the field containing the search term is being used as description so that users see the relevance by first look.

1. – thank you again and again :).
2. Why is it excluded? And will it stay that way, apart from your modification on my server? Am I the first one asking :)?

All the best

Eno

[Author]

Posts