The reason why Cloudflare conflict with latest version of Easyblog is because now the Easyblog composer was loaded single script instead of compression script, I believe there conflict with Cloudflare load the single script on the composer page.

Perhaps you can try read this following how to exclude specific URL from Cloudflare caching and see how it goes.
https://support.cloudflare.com/hc/en-us/articles/200172316-How-do-I-exclude-a-specific-URL-from-CloudFlare-s-caching-
https://support.cloudflare.com/hc/en-us/articles/200168306-Is-there-a-tutorial-for-PageRules-

Exclude these following script folder.
http://yourdomain.com/media/foundry/5.0/scripts
http://yourdomain.com/media/com_easyblog/scripts

If you have using jQuery Easy plugin, try put following script into your plugin settings `ignore script` section and see how it goes?

media/foundry/5.0/scripts/jquery.js

media/foundry/5.0/scripts/lodash.js

media/foundry/5.0/scripts/bootstrap3.js

media/foundry/5.0/scripts/responsive.js

media/foundry/5.0/scripts/utils.js

media/foundry/5.0/scripts/storage.js

media/foundry/5.0/scripts/uri.js

media/foundry/5.0/scripts/mvc.js

media/foundry/5.0/scripts/joomla.js

media/foundry/5.0/scripts/module.js

media/foundry/5.0/scripts/script.js

media/foundry/5.0/scripts/stylesheet.js

media/foundry/5.0/scripts/language.js

media/foundry/5.0/scripts/template.js

media/foundry/5.0/scripts/require.js

media/foundry/5.0/scripts/iframe-transport.js

media/foundry/5.0/scripts/server.js

media/foundry/5.0/scripts/component.js

media/com_easyblog/scripts/easyblog.js

Hi Arlex I assume that these the the rules that should be applied for cloudflare to apply to main and sub domains right?

*.masterfloors.net.au/media/com_easyblog/scripts/* cache level - bypass
*.masterfloors.net.au/media/foundry/5.0/scripts/* cache level - bypass

The issue here is that the whole site runs easyblog meaning it effect the speed of the site.
Is it not better to apply the rules to the url for the composer only?
example
*.mydomain.com/index.php?option=com_easyblog&view=composer&tmpl=component&uid=1&Itemid=/*
will this work
Or some other rules you can think of.

Regards Sam

Hey Sam,

Thanks for getting back to us.

To be honestly, I never configure this before in cloudflare, but based on our customer feedback, they mention that was work after follow the instruction.

example
*.mydomain.com/index.php?option=com_easyblog&view=composer&tmpl=component&uid=1&Itemid=/*
will this work
Or some other rules you can think of.

I am not really sure this will work or not yet, perhaps you can try create a hidden menu item for this composer menu item so that you will get the SEF URL for this composer URL.

After that try set this rule restrict the composer URL into your cloudflare and see is it can work.

If still can't, perhaps you can pass me with your Cloudflare access/ Joomla backend /FTP access and guide us how you put the rules into Cloudflare setting, so we can better have a check?


By the way, in the future you can just include your site's access once at http://stackideas.com/dashboard/site rather than needing to keep adding them in your replies

Hi Arlex

After that try set this rule restrict the composer URL into your cloudflare and see is it can work.

example
*.mydomain.com/index.php?option=com_easyblog&view=composer&tmpl=component&uid=1&Itemid=/*
will this work


After some testing I found out that it wont work because cloudflare works on url level and the following
*.mydomain.com/index.php?option=com_easyblog&view=composer&tmpl=component&uid=1&Itemid=/*
requires the article number. In other words will only work on article by article basis

e.

perhaps you can try create a hidden menu item for this composer menu item so that you will get the SEF URL for this composer URL.

I've already tried the menu approach and the stops all articles being cached. But the composer works Not the solution lol

If still can't, perhaps you can pass me with your Cloudflare access/ Joomla backend /FTP access and guide us how you put the rules into Cloudflare setting, so we can better have a check?

I will do that after I conduct some further testing otherwise my site become useless in the sense that I run HD images and require the extra speed.

Alright, keep us updated then.

Hi Arlex

I found a simple solution
Cloudflare will cache combined scripts so it will deliver what it finds ( wont work with their rocket scripts )

The steps below ensure the correct scripts are being delivered.
If you need to delete the CDN cache in the future the below steps need to be followed.
Adding rules to Cloudflare only complicates things if foundry scripts are not cached there is a massive performance issue.

Caching Sequence

1. JCH script compression off

2. CDN Off

3. Cloudflare Off

4. Clear Cloudflare Cache

5. Clear CDN Cache

6. Clear site cache

7. Click on every menu to re-cache

8. JCH script compression on

9. Click on every menu to re-cache

10. CDN On

11. Click on every menu to re-cache

12. Resume Cloudflare

If Cloudflare cache is deleted it will still deliver the correct scripts because they reside on the external external CDN.

It is a bit of work but its the only way to ensure correct delivery.

Thanks for sharing Sam

To me, it very complicated. By the way, I will keep this in mind, in case other user also facing the same issue, so I can suggest them to follow this instruction.

May i know is it no need set any rule in your Cloudflare server?

After reading the steps I am a little confused. I am running into this problem with my setup. So the confusion comes in when you refer to a CDN, and Cloudflare.

So Step 2 and 3 are the same right? Isn't Cloudflare a CDN, and if so it would combine 4 and 5 and 10 and 12?

Or are you referring to them being in JCH?

Zack

Hey Sam,

Perhaps you can guide Zack regarding this and see is it can resolve this issue when you have free time.

Hi guys sorry about the delay been working long hours.

To remove all confusion.

I use jch compression latest pro version berfore turning any cdn the site needs to be fully compressed. Jch settings will vary from site to site and it might take sometime to get it right.

I also use max-cdn to store all files and scripts - I was using s3 and cloudfront.
When integrating cloudflare for security and content delivery cloudflare must be paused and all cache deleted.

Ensure you upload all new files to your preferred cdn click on all menus and ensure all scripts are being delivered correctly with no conflicts.

Finally resume cloudflare ensure rocket launcher is turned off - it can not be used. It might take a few hours before the site is fully cached on cloudflare.

Hope this helps.

Thanks for sharing Sam

Here's my cloudflare page rule settings. Still not working. Soon as I pause cloudflare everything starts working again. What am I missing?

Hey Stephen,

Perhaps you can start a new thread and provide us with your Joomla backend and Cloudflare access so I can better have a look?

No need. I fixed it about 30 min ago. Cloudflare was ignoring my page rules apparently.

Keep us update if the issue still persists.

@stephen

Turn off Rocket Loader and Auto Minify, set your caching to 1 month (or whatever you need) and you should not need the Page Rules( just edit and pause them by clicking on Draft).

If you want to restrict turning off Rocket Loader and Auto Minify to your blog area, add 'Disable Performance' to your rules and change the first part of your rule from https://*.kin... to just *kin... to cover all 4 types of url (http/https/www. and no www).

It should allow Composer to work.

Thanks for sharing Richard.

Followed those instructions, still does not work. Have to completely disable Rocket Loader site wide then it works as expected. It's almost as if it's ignoring the page rules I have setup. Have a message in to cloudlfare. I'll let you know if they provide a solution.

SOLVED -- I switched the page rules order to as shown in picture. This appears to be critical to getting it to work correctly.

Well ... I stand corrected, worked briefly, now not working again.

@Stephen

The Page Rules sequence works with the most specific first, to the most general last with only the first rule for any exact area on your site being applied.

It is difficult to know exactly what you need without knowing your set up, but if you are with SiteGround and CloudFlare, I can only show you what works for me for all Stackideas products and other similar software:

Joomla
Joomla Cache off
Joomla GZip on
No Force SSL
No JCH Optimize
No JQuery Easy
JSGCache Plugin on

SiteGround
Static Caching (Supercacher)
Dynamic Caching (Supercacher)
No Memcache

CloudFlare
No Page Rules for Stackideas products
Speed - Auto-Minify Off
Speed - Polish Basic+JPeg
Speed - Railgun On
Speed - Mirage On
Speed - Rocket Loader Off
Cache - Caching Level Standard
Cache - Browser Cache Expiration 1 month (or more)
Cache - Always Online On
Apps - None
Rules - *domain.com/administrator/* (Cache Level ByPass, Disable Performance)

For htaccess, use the following as initial core and add/adjust as required:

# BEGIN Compress text files
<ifModule mod_deflate.c>
AddOutputFilterByType DEFLATE text/html text/xml text/css text/plain
AddOutputFilterByType DEFLATE image/svg+xml application/xhtml+xml application/xml
AddOutputFilterByType DEFLATE application/rdf+xml application/rss+xml application/atom+xml
AddOutputFilterByType DEFLATE text/javascript application/javascript application/x-javascript application/json
AddOutputFilterByType DEFLATE application/x-font-ttf application/x-font-otf
AddOutputFilterByType DEFLATE font/truetype font/opentype
</ifModule>
# END Compress text files

# BEGIN Expire headers
<ifModule mod_expires.c>
ExpiresActive On
ExpiresDefault "access plus 5 seconds"
ExpiresByType image/x-icon "access plus 2592000 seconds"
ExpiresByType image/jpeg "access plus 2592000 seconds"
ExpiresByType image/png "access plus 2592000 seconds"
ExpiresByType image/gif "access plus 2592000 seconds"
ExpiresByType application/x-shockwave-flash "access plus 2592000 seconds"
ExpiresByType text/css "access plus 604800 seconds"
ExpiresByType text/javascript "access plus 216000 seconds"
ExpiresByType application/javascript "access plus 216000 seconds"
ExpiresByType application/x-javascript "access plus 216000 seconds"
ExpiresByType text/html "access plus 600 seconds"
ExpiresByType application/xhtml+xml "access plus 600 seconds"
</ifModule>
# END Expire headers

# BEGIN Cache-Control Headers
<ifModule mod_headers.c>
<filesMatch "\.(ico|jpe?g|png|gif|swf)$">
Header set Cache-Control "public"
</filesMatch>
<filesMatch "\.(css)$">
Header set Cache-Control "public"
</filesMatch>
<filesMatch "\.(js)$">
Header set Cache-Control "private"
</filesMatch>
<filesMatch "\.(x?html?|php)$">
Header set Cache-Control "private, must-revalidate"
</filesMatch>
</ifModule>
# END Cache-Control Headers

# BEGIN Turn ETags Off
FileETag None
# END Turn ETags Off

The above should do what is required with no conflict, you can clear Static/Dynamic cache on SiteGround, CCleaner on your computer, test speed at WebPageTest and add/adjust if required to suit your site.

Anyway I hope the above helps.

Thanks for heading up on this Richard

Richard thank you for the assistance, this has been something I have needed for a long time. Man my site just speed up like 50000%. I will post back how it works, but I am too on siteground and use all of stackideas modules and I followed your post to the letter and so far so so good. Thank you again. Will report back on how it goes over the week.

Zack

Richard,
One thing I did notice... My site loads quick, but my gtmetrix.com score is terrible. Is that supposed to happen?

Zack

Don't worry about the GTMetrix score, I was scoring 95%+ and AA before I worked through to the above solution and all my scores dropped but plage load speed increased.... (for example) my home page has dropped to 84/77 and B/C but the page load time is down from 6/7 sec to just over 2.

The same applies to PageSpeed Insights, the key thing is the user experience and if your page load time means he doesn't get fed up and leave, you are going in the right direction.

Only use the GTMetrix and Page Insights scores as a trend guide and for pointing out things that you may need to look at/fix.

Sometimes fixing something they recommend is good in isolation, but causes a conflict because of the complex software we are using, so they are useful in pointing out potential issues but not solutions because they don't know how your site is built.

The one speed test i would go with is WebPageTest, as it the detail is very helpful in eliminating issues and improving page load times.

I used it to work through to the above solution and it produced a near perfect score with AAAAB, so try it on your own site and see how it goes, but again if your site loads fast with no software conflicts you are doing the right thing.

I have tried JCHOptimize and JQueryEasy, very good products but with complex software the potential for conflict as each bit tries to do the same thing increases and in my case I found the site was much more efficient without them.

All sites are different, you just need to keep it as simple as possible and find the combination that works best for you.

One thing i forgot to mention, I am not running on PHP7 yet, as JReviews requires ioncube to be compatible and it is not ready.

One other thing, ref bots and spam, put this in your htaccess just after the joomla core sef section and it should block almost everything:

RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} ^BlackWidow [OR]
RewriteCond %{HTTP_USER_AGENT} ^Bot\ mailto:craftbot@yahoo.com [OR]
RewriteCond %{HTTP_USER_AGENT} ^ChinaClaw [OR]
RewriteCond %{HTTP_USER_AGENT} ^Custo [OR]
RewriteCond %{HTTP_USER_AGENT} ^DISCo [OR]
RewriteCond %{HTTP_USER_AGENT} ^Download\ Demon [OR]
RewriteCond %{HTTP_USER_AGENT} ^eCatch [OR]
RewriteCond %{HTTP_USER_AGENT} ^EirGrabber [OR]
RewriteCond %{HTTP_USER_AGENT} ^EmailSiphon [OR]
RewriteCond %{HTTP_USER_AGENT} ^EmailWolf [OR]
RewriteCond %{HTTP_USER_AGENT} ^Express\ WebPictures [OR]
RewriteCond %{HTTP_USER_AGENT} ^ExtractorPro [OR]
RewriteCond %{HTTP_USER_AGENT} ^EyeNetIE [OR]
RewriteCond %{HTTP_USER_AGENT} ^FlashGet [OR]
RewriteCond %{HTTP_USER_AGENT} ^GetRight [OR]
RewriteCond %{HTTP_USER_AGENT} ^GetWeb! [OR]
RewriteCond %{HTTP_USER_AGENT} ^Go!Zilla [OR]
RewriteCond %{HTTP_USER_AGENT} ^Go-Ahead-Got-It [OR]
RewriteCond %{HTTP_USER_AGENT} ^GrabNet [OR]
RewriteCond %{HTTP_USER_AGENT} ^Grafula [OR]
RewriteCond %{HTTP_USER_AGENT} ^HMView [OR]
RewriteCond %{HTTP_USER_AGENT} HTTrack [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^Image\ Stripper [OR]
RewriteCond %{HTTP_USER_AGENT} ^Image\ Sucker [OR]
RewriteCond %{HTTP_USER_AGENT} Indy\ Library [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^InterGET [OR]
RewriteCond %{HTTP_USER_AGENT} ^Internet\ Ninja [OR]
RewriteCond %{HTTP_USER_AGENT} ^JetCar [OR]
RewriteCond %{HTTP_USER_AGENT} ^JOC\ Web\ Spider [OR]
RewriteCond %{HTTP_USER_AGENT} ^larbin [OR]
RewriteCond %{HTTP_USER_AGENT} ^LeechFTP [OR]
RewriteCond %{HTTP_USER_AGENT} ^Mass\ Downloader [OR]
RewriteCond %{HTTP_USER_AGENT} ^MIDown\ tool [OR]
RewriteCond %{HTTP_USER_AGENT} ^Mister\ PiX [OR]
RewriteCond %{HTTP_USER_AGENT} ^Navroad [OR]
RewriteCond %{HTTP_USER_AGENT} ^NearSite [OR]
RewriteCond %{HTTP_USER_AGENT} ^NetAnts [OR]
RewriteCond %{HTTP_USER_AGENT} ^NetSpider [OR]
RewriteCond %{HTTP_USER_AGENT} ^Net\ Vampire [OR]
RewriteCond %{HTTP_USER_AGENT} ^NetZIP [OR]
RewriteCond %{HTTP_USER_AGENT} ^Octopus [OR]
RewriteCond %{HTTP_USER_AGENT} ^Offline\ Explorer [OR]
RewriteCond %{HTTP_USER_AGENT} ^Offline\ Navigator [OR]
RewriteCond %{HTTP_USER_AGENT} ^PageGrabber [OR]
RewriteCond %{HTTP_USER_AGENT} ^Papa\ Foto [OR]
RewriteCond %{HTTP_USER_AGENT} ^pavuk [OR]
RewriteCond %{HTTP_USER_AGENT} ^pcBrowser [OR]
RewriteCond %{HTTP_USER_AGENT} ^RealDownload [OR]
RewriteCond %{HTTP_USER_AGENT} ^ReGet [OR]
RewriteCond %{HTTP_USER_AGENT} ^SiteSnagger [OR]
RewriteCond %{HTTP_USER_AGENT} ^SmartDownload [OR]
RewriteCond %{HTTP_USER_AGENT} ^SuperBot [OR]
RewriteCond %{HTTP_USER_AGENT} ^SuperHTTP [OR]
RewriteCond %{HTTP_USER_AGENT} ^Surfbot [OR]
RewriteCond %{HTTP_USER_AGENT} ^tAkeOut [OR]
RewriteCond %{HTTP_USER_AGENT} ^Teleport\ Pro [OR]
RewriteCond %{HTTP_USER_AGENT} ^VoidEYE [OR]
RewriteCond %{HTTP_USER_AGENT} ^Web\ Image\ Collector [OR]
RewriteCond %{HTTP_USER_AGENT} ^Web\ Sucker [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebAuto [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebCopier [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebFetch [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebGo\ IS [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebLeacher [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebReaper [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebSauger [OR]
RewriteCond %{HTTP_USER_AGENT} ^Website\ eXtractor [OR]
RewriteCond %{HTTP_USER_AGENT} ^Website\ Quester [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebStripper [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebWhacker [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebZIP [OR]
RewriteCond %{HTTP_USER_AGENT} ^Wget [OR]
RewriteCond %{HTTP_USER_AGENT} ^Widow [OR]
RewriteCond %{HTTP_USER_AGENT} ^WWWOFFLE [OR]
RewriteCond %{HTTP_USER_AGENT} ^Xaldon\ WebSpider [OR]
RewriteCond %{HTTP_USER_AGENT} ^Zeus
RewriteRule ^.* - [F,L]

Put the other other code from the previous post in next, then this at the bottom (additional robot/spam block):

RewriteCond %{HTTP_USER_AGENT} ^$ [OR]
RewriteCond %{HTTP_USER_AGENT} (bot|crawl|robot)
RewriteCond %{HTTP_USER_AGENT} !(bing|Google|msn|MSR|Twitter) [NC]
RewriteRule ^/?.*$ "http\:\/\/127\.0\.0\.1" [R,L]

The above rules come from SiteGround support and have worked very well for me.

Hope your site keeps loading fast!

Also....after any changes you can click on the Static and dynamic flush to see instant results, but remember it is the second page refresh that counts as the first will be slower, being prior to the page being cached.

You can always access all your main menu pages after any major changes and cache purge, just to get the new page caching out of the way.

After much tinkering with various settings in cloudflare/joomla/jomsocial I seem to have it dialed in and working. I do need to find a faster host though, sometimes they just have bottlenecks and the server slows to a crawl. But for now this is what I'm getting and I'm good with it.

Thanks for all the tips, it lead me down the right path to get it right for my host.

Thanks for sharing guys

I just purchased and installed easyblog. My install is as follows:
joomla 3.6.2
cloudflare
jch optimize pro

I tried all mentioned excludes / page rules in cloudflare
None of the solutions mentioned seamed to work here.

I did 3 different installs on different sites for easy blog component and it all has to do with cloudflare I believe. I have same extensions/components same cache levels on all, the only difference is cloudflare on the site that it's not working.

Such a great component I hope the developers work for an easy solution for this. I already spent more time that I wanted on it.

Best,
jc

Hey Juan,

Perhaps you can start a new thread and provide us with your following details so we can better have a look?

- Joomla backend
- FTP access
- Cloudflare access

Hi guys

Easyblog composer definitely does not get along well with cloudflare sometimes it works and at other times will not open categories or any of the composer tabs. Both frontend and backend.

No matter how cloudflare is configured it will not function correctly.

Same goes for the back-end of easydiscuss locking itself up with cloudflare which I believe is a dns conflict .

Turn cloudflare off and all goes back to normal and in some cases clearing cloudflare cache restores functionality.

I have spent over a month off and on testing every possible rule and combinations to get these issues resolved.

Console shows no errors nor is the issues restricted to the type of browser used. Even a clean J installation with one component installed the issue remains.

The situation becomes worse when you allow Quick posts and the composer introduces JCE or any other editor into the equation. Its like the composer is having an identity crisis.

The only stacks component that has no issue with cloudflare is ES.

However during testing I have found a number of major components having issues with cloudflare such as hwd uploading progress screens will not work with cloudflare, one which cloudflare techs have confirmed that it cannot work.

Thanks for sharing Sam.

Based on what you share, It seems like Cloudflare compression is not doing very well even other component also facing the same issue.

If everyone still facing this issue, can you start a new thread and provide us with your Joomla backend and FTP access so we can see if we can provide some quick fix on this.

This may help:

@Juan

Disable JCH Optimize Pro and the settings I listed will work (I do not use JCH).

@Juan/Sam

The Page Rule - *domain.com/administrator/* (Cache Level ByPass, Disable Performance) for your domain needs to be in place to avoid any conflict between CloudFlare and Components/Modules/Plugins in your administration area.

Thanks Richard

I have all the rules in place and Cloudflare plugin is installed and published I've tried JCH on and off it works for a day or so and then it comes to a grinding halt again.

It all really depends on what extensions your running on the one site. If there is a script that is similar in one extension to another I think that Coudflare gets confused. I have several sites running on various domains some sites load in under 2 seconds without conflicts others with slightly different configurations can take up to 6 to 8 seconds with conflicts using Cloudflare. Without Cloudflare no conflict.

One site with easyblog being the only extension installed it is lighting fast, the only issue is the composer.

Yet another site with easyblog and one other extension installed the composer has no issue with Cloudflare. I had to install the other extension on the first site to over come the issue.

Its got me beat. Its not the stack products that are at fault its when they are used in conjunction with Cloudflare and other non Stacks extensions have the same issues

Even isolating the composer script has no effect

*.mydomain/index.php?option=com_easyblog&view=composer&tmpl=component&uid=1&Itemid=/*

Nor if you isolate the entire url due to how Cloudflare caches the scripts.

I've also tried ordering the scripts in different sequences on Cloudflare it only helped load times dramatically but not the composer.

I think that you will find that if you add an extension on your site you might run into the same issue. The issue only started with the composer on the last release where they scripts were no longer loaded individually. Which makes it exceptionally difficult to work out how Cloudflare treats the scripts.
By the way Cloudflare could not shed any light on the issue.

A few observations that I have made:
If you allow users to use both quick upload and the composer it breaks with Cloudflare.
If you use only jce on quick uploads it works till you go back and edit an existing post.

So it really makes no difference how the composer is setup.

I've also found less conflicts when applying JCH into the equation but again it all depends on the extensions used.

What makes a real difference is when you use Cloudflare / Railgun no extensions break. I think it caches in a different manner.

It is a puzzle, Sam, but there is another option to try (I assume you are using a paid version of CloudFlare).

I compared my settings again to my above posts and if you use SSL for the full site, switch it off in the page rule for administrator:

*/domain.com/administrator/*
SSL:Off, Cache Level: Bypass, Disable Performance

The CloudFlare SSL conflicts with some settings in the admin area (you can go through all the settings to isolate the conflicts or just turn off SSL for the admin area if only you access it).

@Arlex

I am not having any problems with Composer (I only use TinyMCE although JCE is available) or any conflict with my components (All Stackideas, AcyMailing, CometChat, JFBConnect, JReviews, JSiteMap, TechJoomla, Mijoshop, Minitek), so if it would help, feel free to access and compare anything on my site with any of the sites that do have problems.

I'm going to wait it out see if the team here finds a solution. It probably has everything to do with CloudFlare and DNS conflict with easyblog editor. As mentioned I have identical installs and site that is on CloudFlare does not work despite having exclusions mentioned or disabling / turning on "development on" to bypass entire site. All solutions to turn off cache, clear cache, disable JCH did not work. I have several different components, extensions, plugins, and most have no conflict or have a work around with CloudFlare.

That's fine Juan, I will give Stackideas whatever help/access I can and hopefully it will be resolved for you soon.

There is definitely a conflict with EasyBlog as the script is loaded as one file now, possibly with these scripts that I excluded before deciding to apply a different rule to all of the admin area:

Cache Level ByPass
Disable Performance

for

*yourdomain.com/media/foundry/5.0/scripts*
*yourdomain.com/media/com_easyblog/scripts*

(with yourdomain ignoring the http://www. part of the url)

hey Richard,

@Arlex

I am not having any problems with Composer (I only use TinyMCE although JCE is available) or any conflict with my components (All Stackideas, AcyMailing, CometChat, JFBConnect, JReviews, JSiteMap, TechJoomla, Mijoshop, Minitek), so if it would help, feel free to access and compare anything on my site with any of the sites that do have problems.

Thank for help, will do. But I am not really sure how to access your Cloudflare server, perhaps you can send me regarding this information into my email address. (arlex.wong@stackideas.com)

===============================================================================
hey Juan,

I'm going to wait it out see if the team here finds a solution. It probably has everything to do with CloudFlare and DNS conflict with easyblog editor. As mentioned I have identical installs and site that is on CloudFlare does not work despite having exclusions mentioned or disabling / turning on "development on" to bypass entire site. All solutions to turn off cache, clear cache, disable JCH did not work. I have several different components, extensions, plugins, and most have no conflict or have a work around with CloudFlare.

It would be best if you start a new thread in our forums and can provide us with your Joomla backend, FTP and CloudFlare access so I can better have a look.