Upcoming releases. What to expect.

OK, I am going to play around with it then.

Hmm. I don't really remember it. But perhaps i either misunderstood, or did not know what that setting fully did at the time.

Anyhow, yes, when i get done with this, it will be much easier.

/**

 * Based on: http://sachachua.com/blog/2011/08/drupal-html-purifier-embedding-iframes-youtube/

 * Iframe filter that does some primitive whitelisting in a somewhat recognizable and tweakable way

 */

class HTMLPurifier_Filter_MyIframe extends HTMLPurifier_Filter

{

    public $name = 'MyIframe';

    /**

     *

     * @param string $html

     * @param HTMLPurifier_Config $config

     * @param HTMLPurifier_Context $context

     * @return string

     */

    public function preFilter($html, HTMLPurifier_Config $config, HTMLPurifier_Context $context)

    {

        $html = preg_replace('#<iframe#i', '<img class="MyIframe"', $html);

        $html = preg_replace('#</iframe>#i', '</img>', $html);

        return $html;

    }

    /**

     *

     * @param string $html

     * @param HTMLPurifier_Config $config

     * @param HTMLPurifier_Context $context

     * @return string

     */

    public function postFilter($html, HTMLPurifier_Config $config, HTMLPurifier_Context $context)

    {

        $post_regex = '#<img class="MyIframe"([^>]+?)>#';

        return preg_replace_callback($post_regex, array($this, 'postFilterCallback'), $html);

    }

    /**

     *

     * @param array $matches

     * @return string

     */

    protected function postFilterCallback($matches)

    {

        // Domain Whitelist

        $youTubeMatch = preg_match('#src="https?://www.youtube(-nocookie)?.com/#i', $matches[1]);

        $facebookMatch = preg_match('#src="https?://www.facebook.com/video/embed#i', $matches[1]);

        $dailymotionMatch = preg_match('#src="http://www.dailymotion.com/embed/video/#i', $matches[1]);

        $metacafeMatch = preg_match('#src="http://www.metacafe.com/embed/#i', $matches[1]);

        $vimeoMatch = preg_match('#src="https://player.vimeo.com/#i', $matches[1]);

        $yahoonewsMatch = preg_match('#src="https?://news.yahoo.com/video/#i', $matches[1]);

      $bitchuteMatch = preg_match('#src="https?://www.bitchute.com/embed/#i', $matches[1]);

    $smuleMatch = preg_match('#src="https?://www.smule.com/recording/#i', $matches[1]);

        if ($youTubeMatch || $vimeoMatch || $facebookMatch || $dailymotionMatch || $metacafeMatch || $yahoonewsMatch || $bitchuteMatch || $smuleMatch) {

            $extra = ' frameborder="0"';

            if ($youTubeMatch) {

                $extra .= ' allowfullscreen';

            } elseif ($vimeoMatch) {

                $extra .= ' webkitAllowFullScreen mozallowfullscreen allowFullScreen';

            } elseif ($metacafeMatch) {

                $extra .= ' allowFullScreen';

            } elseif ($facebookMatch) {

                $extra .= ' allowFullScreen';

            } elseif ($yahoonewsMatch) {

                $extra .= ' allowFullScreen';

          } elseif ($bitchuteMatch) {

                $extra .= ' allowFullScreen';

            } elseif ($smuleMatch) {

                $extra .= ' allowFullScreen';

            }

            return '<iframe ' . $matches[1] . $extra . '></iframe>';

        } else {

            return '';

        }

    }

}

Uh, I thought I asked about this and you said something along the lines of, "No, that can't be used for what I wanted."  I cloned the old YouTube safe embed and created one for my whitelist.  This is on an old Dolphin site that I was going to migrate to Cheetah.  Let me go grab what I have and show.  It has to be manually edited.  So maybe I can have something easier now.

Question for you. How have you been allowing the embeds?

Through code modifications(the old way),

or by the Safe iframe URI regular expression section in the security settings in admin which is the new way of doing it as of html purifier version 4.4.0

EDIT: Oh, i forgot. You did mention you modified code.

Well, any developer should be able to add in a site not included in the base code.

My users are use to using an embed code to add videos so I will probably continue to maintain my embed whitelist though the htmlpurifier.

Unfortunately not easy. Each site is different in how it has to be parsed to obtain the needed data.

How difficult would it be to have a form in the backend where admins could add a list of allowed sites?  Or is that like building a collider?

I am not experienced in the list of porn sites.  However, I do assist on adult related sites.  If I recall, there was one client that wanted to be able to scrape from xhamster.com; so you might want to include that as an adult site.

I have been adding in some of the alternative sites; I suggest Rumble, BitChute, and perhaps GabTV (not sure if Gab is allowing one to embed videos or not but it is one of the fastest growing social sites), Brand New Tube (brandnewtube.com) and I also allowed embedding Facebook videos to my site.

Correct.

Yea, sorry. Should have been more clear that this is the video module embeds. Not for allowing embeds in forum posts and such.

Instead of embedding, is this going to be where you grab the video url from the browser address bar and just paste in the URL and the code will do all the rest?

If you recall, I discussed about using whitelisting where you list allowed sites that can be embedded and all others excluded.  The ones that allow you to embed using an iframe; they provide the iframe code to use.  I used regex to simply test if the URL was from the allowed site; such as https://my-video-site/video-embed/  If someone tried to embed a video, then it would check to see if it matched an entry in the whitelist.  If someone tried to embed https://my-video-site/video-embed/hack then it would be rejected.  My method does require the admin to activity add the regex matching; in my case I had to edit the entry in the htmlpurifier.

Sweet!

I am expecting sometime next month.

Awesome!! is there a date or month to expect this release?

Another upcoming feature being developed and tested on https://dev10.cheetahwsb.com is the ability to embed videos from more sources then just youtube.

Currently supporting and testing videos from YouTube, Vimeo, TikTok, Dailymotion and Twitch.tv.  and for adult sites, Pornhub and Redtube

Warning. The test site may contain adult content while testing the adult video embeds.

So, other than the above mentioned sites, does anyone have any suggestions for others that should be included. NOTE: I can only include sites that not only provide embed codes, but also allow curl to obtain page info without blocking it, which some unfortunately do. In fact, the only way i could get pornhub videos was to shell out and use wget instead of curl. Currently researching that one a bit more as i don't want to have to use that method.

That will come later. The current update system relies on the version numbers being as they are. I need to leave that in place for now until i am sure i no longer need it.

Question:  Will the new versioning system be in the next release?

If I recall correctly, there were many posts in the old Boonex forum asking about notifications.  I guess it was never a concern for the Boonex team.  I will be working on a module that needs to send notifications in real time; I will just have to stress for now that the spy module will need to be installed as I will try to work through that.

Update: As pointed out in the first post of this thread, a new update system will be introduced into cheetah. That update system is about a month or so away from completion. When it's finished, a new update to cheetah will be released and with any luck, the last update using the old system. The new one should make updates far easier. I have also be squashing more bugs that i have been finding for anyone watching the commit history on the GitHub page.

On a side note: I was recently asked about classes built into cheetah to send notifications. Per some research i have done, as i suspected, there aren't any. Notices of new mail appear to be handled by the member menus code as well as the 3 second popup that appears. And notices of new friend requests and any of those popups are handled by the spy module. The spy module has to be installed for the notification icon to appear in the member menu.

This lack of a decent notification system is something i am going to need to correct. The notification area and it's functions should be part of cheetahs core. Not part of the spy module or scattered into various areas.

Speed is huge!!! There is no way in today's world that people will be attractive to a slow site. Cheetah will rock!!

I think it's important to look at who will be the average person wishing to use Cheetah? Are we catering for a TOP-END user base who can handle all these server and database settings with ease, or the Average Joe who struggles to make sense of how Page Manager works. I'm at the Average Joe end of the spectrum I just want to present a good social networking script to my users and I'm not overly concerned if TinyMce or whatever will allow for emojis. Speed is still important. Places like Australia and even the USA where the Internet isn't up to scratch, anything that slows a program down should be considered fatal.

It's possible. Because of how InnoDB works, the database server needs to be properly configured in regards to key_buffer_size and innodb_buffer_pool_size based on the amount of ram the server has. And the more ram the better.

Probably other tweeks as well. InnoDB is suppose to be faster. But i don't see it. But i also don't have time to play with it. And if it requires a ton of server tweeks to get it to perform the way it's suppose to, then i can't expect those that use Cheetah to do all of that.

I wonder if that is the reason UNA is so much slower than Cheetah?  I think UNA is fully using InnoDB engine.

Ok. Update on the database conversion. After much testing and consideration i have decided not to convert the entire database over to InnoDB and utf8mb4.

Reasons.

1) It is slowing down database operations.
2) It takes 3-4 times longer to install and uninstall a module.
3) If someone selects all modules to be installed, the script will timeout in the middle of the operation which can cause other problems.
4) The actual conversion on even a empty site takes close to 5 minutes. A fully loaded site, i don't even want to guess as to how long it will take. And the upgrade script will timeout before it is done as it did with me.

I am not willing to sacrifice that much speed for the convenience of full Unicode support.

Thus i have decided i will convert only the tables that need converting to support the full Unicode character set where needed.

So this database upgrade will be delayed for a while while i figure out what tables i need to do and the best way of doing it.

Yes, this was also a complaint I had from users.  If you go to the circle it would tell you the problem but many had trouble understanding that.  

I'm not suggesting Cheetah should look or work like Wiccle. I simply agree with the Boonex member that some of the latter's features are good and "could" be a big plus if incorporated into Cheetah.

I've since been able to get Wiccle to work by entering a registration code I found somewhere into the database. I won't be using it as a working site because several organisations claim it was vulnerable. However, it will be interesting to explore some of the features that could find there way into Cheetah, considering Wiccle's code was open source.

Here's one of the features I mentioned some time ago in the Suggestions section if I recall. Where Cheetah/Dolphin displays an asterisk if a field has been incorrectly filled in, Wiccle actually states what the problem is. This is exceptionally handy for dyslexic people like myself, or people using smaller screens where the asterisk may be easily missed. 

Most scripts that offer this facility usually say "User name or password are incorrtect". Wiccle actually tells you which one is incorrect. For example, if you enter the correct password, but the wrong user name, the message will read "User xxxx not found!"

I think it's highly unlikely that Modzzz will focus on Cheetah soon, and it's most unlikely that Anton ever will. 

I suggest that Cheetah users continue to purchase 7.4.2 compatible modules from the Boonex store and convert them to Cheetah using Deano's existing converter, or wait until it's included with cheetah. I don't see any problem with this approach. The user agreements on the modules I've looked at say "one site only" and do no specifically specify a Dolphin site. I feel that Modzzz in particular would rather get money from existing modules instead of wasting money converting his modules for a small user base.

Provided Cheetah can actually use the converted modules, I don't see any problem with this.

If there isn't a web site or YouTube presence for Cheetah, it will be very difficult to market.  If you do a Google search for any of of the following,  the results should be of interest:

- Best social networking script
- Best script like facebook
- Best content management script
- and dozens more

Dolphin, UNA, or Boonex are rarely, if ever mentioned. Even sites reviewing the best 20 - 50 social networking scripts fail to list any of these for some reason. This is odd considering that Dolphin has been around for years.

When Deano updates the database, he's literally done everything he can to bring the script into the 21st century, except for one thing: How easy it is for admins to develop a site. 

In my opinion, ease of use for admins should be the number one development priority. This needs to be supported with a manual and lots of tutorials on YouTube. Deano, I somehow think you can't possibly do all this alone. I've written a couple of tutorials, but they're a drop in the bucket. In a few months I'll be 80, my main interest is scale model making and I just don't have time to do much more.

I feel there's a need to develop a support group, something Geek_Girl touched on right at the start. That may attract outside programming people who are ready to contribute. With sites like Discord and even this forum, it shouldn't be difficult to organise such a group and keep it focused. 

A Boonex member once wrote to me and said if Boonex obtained the defunct Wiccle and used many of the features it offered, Dolphin would be the best script in the world. I was only able to obtain the free version of Wiccle that had to be registered for ongoing use after a 14 day trial. Unfortunately the registration page closed down when Wiccle folded, so I was locked out. I only used the Admin section, but there were some very interesting features there and I could see where the Boonex member was coming from. Despite the company closing down over unresolved internal disputes, Wiccle was never taken up by someone else. Having said that, there's a mountain of documentation out there and heaps of tutorials on YouTube.

I have a feeling that Wiccle's template was made up of graphic elements, Thus it may have been difficult to change the design. I was hoping to find out but . . .

Thank you Deano; you will be surprised at how many UNA sites got trashed because auto updates were in place.  Users would come in the next day after an update to find parts of the site no longer working.  One of the first things I do with a client's UNA site is to turn off auto updates.

This sounds great Deano; you are creating a first rate platform that will be sure to entice more users.  There are many that went to UNA and are not that happy with the decision.  I have talked to Modzzz and he has shown some interest in converting his modules to Cheetah.  At the moment, he is busy converting them to the UNA platform.

That's fine and as for other developers, hopefully they will see Cheetah as a bad a** platform.

As i am sure many of you are aware, we do not have any module developers here providing modules for Cheetah. Thus those that use Cheetah are still forced to use Dolphin modules on their sites. The lack of developers is a bit disappointing, but it is what it is, and i need to move forward and at the same time make things as easy as possible for those that are using Dolphin modules.

So with that said, i would like to point out a few changes i will be making to make things not only easier for you, but easier for me as well.

1) Cheetahs Database will be upgraded. This change is switching from standard utf8 collation to utf8mb4 collation. This will allow for the full unicode character set to be supported by Cheetah. The second part of the database upgrade is switching from the old MyISAM database engine standard to InnoDB. A more modern database engine which is becoming the new standard.

2) Cheetah will be switching from the Symantec versioning system to the CalVer versioning system. This change i had mentioned from the beginning and i noted on the sites release schedule page. Versions will switch from something like this. 1.2.0 to something like this. 21.12.13.

In that example 21.12.13 can be represented as December 13, 2021. The version is basically the date it was released as YY.MM.DD

Also note that this will create a compatibility issue with 3'rd party modules due to the fact that the compatible with setting in the modules config file will not match the new versioning system. This will be resolved by removing the compatibility requirement check for the time being. It will remain disabled until module developers get onboard with this project.

3) Cheetah will have a built in updater that will allow for updates to be released into beta and stable channels to be downloaded by Cheetah. There will also be built in editors powered by ACE to allow update files to be patched easily by the end users before the update is installed. The update system does not automatically install updates.

This update system will replace the current way that Cheetah is updated. This is being done mostly for my benefit because it will improve the speed in which i can provide updates.

Once this new update system is in place, updates will be released as i develop them. Every 6 months the full installer that will be available for download will be updated based on the current version at the time i create the full install package.

4) Cheetah will have a built in Dolphin module converter. This will make things easier for you. You can just simply upload the module to the site as it would be on a dolphin site, and when you go to install it, Cheetah will detect that it is not been converted for use with Cheetah and will ask if you want to convert it.

Having the converter built in also allows me to keep it updated easier and will also be able to help me deal with any future changes i make to Cheetah that might affect 3'rd party modules.

These above changes i plan on making through December with the last one maybe in January.

I wanted to get these things out of the way for the start of the new year. Once that new update system is in place i will be able to work on things faster and more efficiently.

The database change will be the first of the changes to be released and will be soon. Within 1 to 2 weeks.