DReffects2

Glad to be of some assistance even if it's not what you were hoping for😉 

Ah, too bad. Thanks for the response and clarification.

Thank you for reporting, this will be resolved in a future release.

I have tagged our developers on this to advise. Someone will be in touch on this

Not at all. Its simply moved to System>Site Features>Integrations

Hey Matt, thanks! I was able to figure things out for the moment by modifying (\IPS\Text\Parser::isAllowedImageUrl()) a little bit to enable base64 encoded jpegs and filter out everything else base64 encoded but of course that's a hack.
The filtering is really good in preventing harm even from experienced users but I'd like to see a "true" html option where nothing is filtered. For ckeditor the content filter is actually turned off entirely in IPS.
❤️

Unfortunately this is caused by the CKEditor which is the basis of our editor. I'll have a look and see if there's a plug-in or other solution.

Yeah, looks like there's a method in the editor parser (\IPS\Text\Parser::isAllowedImageUrl()) that will convert an illegal image element to <span> if the image source is not allowed. The first condition in this method is if the source is a valid URL.

The _title is a hash value, so the equal check with "Episodendatenbank" will fail! you should use always use the id for such checks!
    /**      * Get database name      *      * @return string      */     public function get__title()     {         return \IPS\Member::loggedIn()->language()->addToStack('content_db_' . $this->id);     }  

Have you tried this?
 

$item in this case is an instance of \IPS\cms\Records, a Pages database record.
This class has a method called "database()" that returns the reference to the database the record is stored in.
From there you want the title, which is accessible via the magic "_title" property.
A database is a node model: https://invisioncommunity.com/developers/docs/fundamentals/nodes/working-with-node-models-r28/
 
A database record is a content item model: https://invisioncommunity.com/developers/docs/fundamentals/content-items/building-a-model-for-content-items-r78/
 
 

Getting people to join is a struggle - even if you have created something that you believe should interest specific groups of people.  User interaction is important to any Admin especially if they want to know that they are moving in the right direction.  Post before register is a good start, but how about letting guests vote in polls and allow them to rate articles and topics using the star system.  This can go a long way to helping admins understand what is and what is not appealing.  Getting someone to register just to say that they like or dislike something is never going to happen, but give guests a little more leeway and it might just tempt them to register and take advantage of everything else on offer.
I have no idea how this could be implemented, but I'm sure there must be a way.
😉

I agree 100%.
What it's forced me to do is put everything in the main body / description so it will be included in a search.  Which does get around the search problem but wrecks any idea of having certain types of data separated out for uniformity and other database type purposes.  Like you said.... pretty much useless.
Which also begs the question.... The solution to not include extra fields in search results only speeds things up by having less data to process (odd solution for a search problem, as we want data and content).  But, since that forces us to put the data in an area that is indexed, the net result is the same (performance wise).  Sadly, this decision just causes us harm as now instead of having clean, uniform database like structures - we are basically left with the equivalent of static html pages.
It causes us a whole lot of extra work and we loose all the benefits of a database.
 

I was there at the beginning of time... :(

Looks like i still cannot search custom fields which makes the whole pages custom databases pretty much useless...
Any update on this?

I was there at the beginning of time... :(

Count me in as someone who thinks being able to search extra fields is critical.  I was shocked to learn that extra fields are not searchable.  I mean... what's the point of having them if they cannot be found?
I read earlier in this thread (2016) that IPS was focusing on Engagement and would get back to this issue.  But, it's 2019 and it's still not done?  I am well aware of the challenges and hard work that goes into these things and I don't mean to be pushy, but I would think the "fundamentals" would be a top priority.
Being able to search and find the content you are looking for is 100% necessary to keep users engaged and using our sites.
If they can't easily find what they are looking for they will just leave and what does that do for "engagement"?
I wish that was not the case and people would slow down and take the time to look around - but they won't, if it's easier somewhere else.
So, please consider making this issue a bigger priority than it has been.

Looks like i still cannot search custom fields which makes the whole pages custom databases pretty much useless...
Any update on this?

Should be a few more weeks and will get to this particular plugin.