WE Deployment Issues

I’ve been fielding a number of emails from folks that are having Web Edition deployment issues.  I think this is mostly because of the Real Studio training videos that show how to install a WE app on my BlueHost shared hosting account and on my MyHosting VPS account.

On the BlueHost account I could only get it to work if the Web Apps were placed in the cgi-bin directory.  Otherwise, I had no special settings for PHP and the Apache Handlers were already setup to handle cgi applications.

The VPS account took a little more work as I had to installed the 32-bit compatible libraries via the SSH shell.  This was kind of scary since I’m in no way a Unix guy, but I had no problems and it seemed to work.  On this account, I found I could NOT install the apps in the cgi-bin directory, but I could put them in the directory of my choice.  The only modification that I needed was the .htaccess file generated by Real Studio for every project.  I had to add the following line to it:

AddHandler cgi-script .cgi

If I don’t add this line, the browser will simply display the text in the cgi file.   I’m sure I could modify this file on my account, but so far have not found the location of it and frankly, this solution isn’t very hard or time consuming and it’s very easy to spot.

A couple of things that seems to affect your outcome:

1.  Make sure permissions are set.  The app folder and all of it’s contents MUST be 755.  My FTP client, Transmit, lets me do this via its Get Info command.  It even has a preference setting to allow me to set this automatically.  The times when my app fails to launch I’ve forgotten to do this.

2.  Uploading the entire directory.  Many of us are on Mac OS X so we don’t even realize that there’s a hidden file in the build directory, named ‘.htaccess’.  This file contains instructions for the server on how to handle the cgi file.  If you forget it, it will fail.

3.  Binary transfers.  People that have been using FileZilla have had this problem.  For some reason, it’s transferring the files as text and that messes things up.  Have it transfer the files as binary.  I’ve had no issue with Transmit.

What would be really useful is if the IDE allowed me to FTP the files automatically into the proper location on my server and set the permissions for it automatically.  It would also be nice to have a hook into a running application that could force it to quit and install the new version, or, somehow have it wait until the app has quit and replace the files it needs to.

All-in-all, I’ve found 2011 R1 Web Edition apps to be fairly safe and reliable.  The speed is a little slow, but I suspect it will get better over time.  To be truly useful it needs some tweaks here and there and some major features added, but in reality this is version one.  2010 R4 was really a beta version and R5 (released in 2011) was another beta and RS realized that trying to do FastCGI just wasn’t going to work.

Any other questions?  Tips?  Rants?

Here’s a listing of the current Web Edition samples on the website.  Most don’t do much accept demonstrate the events and a few of the methods available for each control.














WebSession (formerly Fun Facts)




Currently we have Google’s reCAPTCHA working and will post a video and sample project on that in the next couple of weeks.  And more to come!

8 thoughts on “WE Deployment Issues

  1. Thank you for the demos Bob – they clearly show the useless-ness of RB web-apps when used outside of a LAN and the weak support of browsers and functions (for example WebPopup works in FF and Safari but not in IE8 – it does work in IE9 RC though…)

    Maybe I am wrong, but as a fulltime web-developer I stick out my neck and claim that if this is Web 3.0, the web is doomed. I am so angry with RS about this waste of time that I will need to cool down and then start writing up an article for ARBP or the Developer Magazin. Focusing development resources, customer patience and testing efforts on this is simply (for lack of a better word)… pathetic.

    FYI but I tried the demos on iOS 4.3 (iPad and iPhone) over both ADSL and 3G from Sweden (RTT to your server 285 ms so it takes some time for UI to stabilize after moving the mouse and waiting for all messages to be passed between the client and the server). I am amazed to see how different the UI shows up in all these browsers (centerd, non-centered, alignment shows up different some texts are chopped off etc. etc)

    Thanks for the demos and sorry for the rant 🙂

  2. Well, personally I think the example projects are really poor examples as all I was doing was looking at events. Coming from the desktop environment that’s what I’m used to dealing with when in reality I think you should probably stay away from the events as much as possible.

    I dunno, but I’ve used WE on a commercial site and it worked just fine. In fact, I’d say the development time wasn’t much different than if I had done it as a regular desktop app.

    Of course there are differences and some of them are maddening but I’m coming from the desktop side. Unfortunately I don’t know what I don’t know when it comes to web development.

    I hope to get a more realistic example or two out in the next month or so. Business is picking up again so extra time seems to be missing.

  3. Hello, can you explain how did you istalled the 32-bit compatible libraries via the SSH shell ? Thank you.

  4. Matthias, there are some things you should know. Like that on a web app you don’t use all events normally as each event requires a request being sent to the server.

    So if you use mouse move events, you app is going crazy with sending an event for each mouse move which can be a lot. So better you think what controls to use and what events. The key thing is to minimize those requests. for example one app from me uses mousedown for detail info on a chart while on desktop you’d normally use mousemove for that.

    Take a look on the web apps here:

    Server is in located in Germany. Depending on where you are the round trip times can be longer than 200ms.

    Greetings from Atlanta,

Comments are closed.