WADE 4.0 beta
Gio

Hi all

We are getting close to the long-awaited WADE 4.0 release. It contains A LOT of changes, and although we've tested it as much as possible, there may be things that aren't working quite perfectly.

So I was thinking to give access to it to a few people only for a week or so before releasing it to everybody. It will still be missing some final touches but it's mostly done, so I'm calling it a beta version.

If you want to participate, you'll get access to it starting next week, and you could try it for a bit and report anything that you think is broken.

Anybody wants to help? If so please reply here or PM me.

Thanks

Comments 16 to 23 (23 total)
Gio

I've released it now, fixed most of the things you guys mentioned. More fixes and features coming in version 4.1 - minor releases should happen more frequently now.

Thanks everyone for your help

krumza

Gio, please install ssl cert for online editor

but becase forum - ssl be with warnings - mixed content,

may be carry online editor on subdomain - like editor.clockworkchilli.com and get ssl for it

Gio

I do agree with you, but I want to move the entire site to https not just the editor.

Unfortunately this isn't very easy. It's actually not too difficult for the website and forum, but for the editor it's going to be a nightmare.

This is because once we move to https://clockworkchilli.com, it is technically a different domain. And the FileSystem API that we use to store all your projects is tied to a specific domain.

So the day after we do this, everyone will be complaining because their projects have disappeared, and they can no longer access them.

We can give advance warnings and provide ways to access the FileSystem on the old http domain to get your projects back, but I'm sure this won't stop people complaining :)

At some point I'm going to do it anyway though... and I think it should happen in the next few months.

krumza

I'm sorry if I'm saying the obvious things you know!

Gio, it so easy if use nginx as proxy

And I see that you and statics(css,js, images) hand out through Express

But give it not via Express but via nginx is much more profitable and cheaper for the server - read about it in more authoritative sources than me

 Nginx is a lot faster than node at serving static files & performing optimizations such as gzip and caching.

moreover, the latest versions of nginx are very easy to configure to http/2

something like this :

http {
	##
	# Gzip Settings
	##

	gzip on;
	gzip_disable "msie6";
	gzip_vary on;
	gzip_proxied any;
	gzip_comp_level 6;
	gzip_buffers 16 8k;
	gzip_http_version 1.1;
	gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;

##catch no-https requests and redirect them to https
	server {
		listen 80;
		server_name clockworkchilli.com www.clockworkchilli.com;
		proxy_set_header Host clockworkchilli.com;

		location / {
			rewrite ^(.*)$ https://clockworkchilli.com$1 permanent;
		}
	}
##catch request to https://www.... and redirect them to non-www version
	server {
		listen 443 ssl;  
		server_name www.clockworkchilli.com;
		proxy_set_header Host clockworkchilli.com;            
		ssl on;                                        
		ssl_certificate /path_to.crt;      
		ssl_certificate_key /path_to.key;

		location / {
			rewrite ^(.*)$ https://clockworkchilli.com$1 permanent;
		}
	}
##main logic

	server {
		listen 443 ssl http2;  
		server_name clockworkchilli.com;
		proxy_set_header Host clockworkchilli.com;            
		ssl on;                                        
		ssl_certificate /path_to.crt;     
		ssl_certificate_key /path.key;
		root /where_now_your_public_dir/public/;
		access_log off;
		error_log /path_to_logs.log error;

		proxy_set_header X-Real-IP $remote_addr;
		proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
		proxy_set_header Host $http_host;
		proxy_set_header X-NginX-Proxy true;

        location ~* \.(jpg|jpeg|gif|png|ico|txt|woff|otf|eot|svg|ttf|html|xml|css|js|mp3)$ {
            expires max;
            error_page 404 @notfound;
        }

		location / {
			proxy_pass http://52.25.187.234:your_port;
			proxy_http_version 1.1;
			proxy_set_header Upgrade $http_upgrade;
			proxy_set_header Connection "upgrade";
			proxy_set_header Host $host;
		}

        location @notfound {
            proxy_pass http://52.25.187.234:your_port$request_uri;
        }

	}


}

 

krumza

God, I just noticed you don't cache anything. In my opinion it is a crime)) the forum page should not be opened for 2 seconds.

Along the way, and my God how many mistakes(( you haven't set up a 404

app.get('blabla...', function(req, res){
...
})	
...

//after main route sections add 404-cathcer

app.get('*', function(req, res){
		res.status(404).render('404.ejs', {
			//what you want
		});
});

 

Gio

I appreciate the heads up but resources are spent where they are needed, the website is "good enough" for now. Sure it's not perfect but optimizing it is not a priority either, the server is running nowhere near its capacity (also there's a reason for the lack of 404's but it's a long story...).

Anyway I agree regarding the lack of https, that's something to do sooner rather than later. I'll try to see if we can make it happen in a way that's not too inconvenient for users with existing Wade projects that will need to be moved.

krumza

using nginx-really no one will notice anything even. the only problem is setup and installation -

but damn it a few minutes-

apt-get install nginx

apt-get service nginx start //there is likely to swear because you are on port 80 

config for the file nginx.conf I wrote without errors

and there should be no problem with the file system

you can try to start a copy of your site on port 8080 for example and already there to look with the self-signed certificate - whether logic will break or not (but should not break anything if to use proxying) well it is not pleasant nginx- use apache2
 

Gio

That's not what I meant, sorry if I didn't explain it clearly above. It doesn't matter whether we do it with Express or nginx, the problem will be the same and is the following:

Now you use Wade on http://clockworkchilli.com, work on your projects and save them.

Even though these projects are saved on your hard drive, when you then use wade on https://clockworkchilli.com, you can NOT access those projects anymore. This is because the FileSystem API that we use to save your projects is sandboxed for each domain, and http://clockworkchilli.com is not the same domain as https://clockworkchilli.com

So for existing users their projects will disappear when we redirect http to https.

Something similar has happened before, when we started redirecting www.clockworkchilli.com to clockworkchilli.com (without www). We had to do it for SEO reasons, it was inevitable. But it did cause a lot of confusion and frustrated users.

I think I can probably figure out a way around the problem though, so hopefully we'll make the switch soon.

Post a reply
Add Attachment
Submit Reply
Login to Reply