Posted on Leave a comment

Rails: Two different layouts with two different CSS frameworks

I have said it before. Rails is awesome. I find myself creating a new web application in Rails rather than, say, ASP.NET or even PHP much more often. It is intuitive and uncomplicated. Command-line tools and pre-handpicked components allow me to focus more on writing code and implementing business logic.

While working on a Rails application, I was faced with a (reasonably) common situation — having one layout for the end-users and another for administrators. I had my admin pages all written and finished. My CSS framework of choice at the time I started was Ink, mostly because of its fresh UX and Bootstrap‘s aging grid system. When I was about to start with end-user pages, I found out about the release of Bootstrap v4.0.0 (something I had been waiting for since long). The examples made using this version were very much in line with what I wanted for my own purpose. I had made a decision: use Bootstrap for end-user pages and stick to Ink for the admin interface. Realizing this decision in Rails was not as easy as I had thought.

As good as the Rails documentation is, I frequently find myself wanting for more code snippets and examples for things that are apparently presumed to be too basic to explain. After stackoverflowing into the problem and applying some common sense, I came up with the following solution.

Continue reading Rails: Two different layouts with two different CSS frameworks

Posted on Leave a comment

WordPress: Internal Server Error (500) after moving to new location

You follow the official WordPress migration documentation and still end up with the dreaded internal server error. This little incident launches you into panic mode. You spend the next 30-60 mins googling a fix for this godforsaken situation. Most of the solutions you come across mention something about fixing/deleting your .htaccess file. Alas, that doesn’t work for you. Not even disabling all plugins. What do you do?

Chances are your WordPress installation’s file permissions are screwed, as happened with me during my recent spring cleaning. After wasting some time googling for solutions, I ended up realizing that file permissions for all my WP files were reset to 640 (-rw-r—–). And I had only moved my installation to another directory on the same server. None of the solutions that I came across on Google talked about file permissions as a potential problem. So I thought I’d share this little fix.

The fix is simple. If you have access to your web server via ssh, you can execute the two commands mentioned on Hardening WordPress page.

find /path/to/your/wordpress/install/ -type d -exec chmod 755 {} \;

find /path/to/your/wordpress/install/ -type f -exec chmod 644 {} \;

Otherwise, manually change the permissions via an FTP client.

Posted on Leave a comment

Running opentaps in Windows

So I’m playing around with opentaps these days. It runs pretty neatly in Linux. Simply executing a shell script it comes with autostarts a built-in Tomcat server and runs the darn thing without a hitch. opentaps under Windows is another animal!

Although opentaps comes with a similar batch script for Windows, the thing doesn’t run without errors. With JDK and all set all right, I was getting this error when visiting opentaps in browser:

HTTP Status 500 –

type Exception report

message

description The server encountered an internal error () that prevented it from fulfilling this request.

exception

java.util.regex.PatternSyntaxException: Unexpected internal error near index 1
\
^
java.util.regex.Pattern.error(Pattern.java:1713)
java.util.regex.Pattern.compile(Pattern.java:1466)
java.util.regex.Pattern.(Pattern.java:1133)
java.util.regex.Pattern.compile(Pattern.java:823)
java.lang.String.split(String.java:2293)
java.lang.String.split(String.java:2335)
org.ofbiz.webapp.control.ConfigXMLReader.injectControllerIfNeeded(ConfigXMLReader.java:81)
org.ofbiz.webapp.control.ConfigXMLReader.getControllerConfig(ConfigXMLReader.java:133)
org.ofbiz.webapp.control.ConfigXMLReader$ControllerConfig.loadIncludes(ConfigXMLReader.java:351)
org.ofbiz.webapp.control.ConfigXMLReader$ControllerConfig.(ConfigXMLReader.java:170)
org.ofbiz.webapp.control.ConfigXMLReader.getControllerConfig(ConfigXMLReader.java:132)
org.ofbiz.webapp.control.ConfigXMLReader$ControllerConfig.loadIncludes(ConfigXMLReader.java:351)
org.ofbiz.webapp.control.ConfigXMLReader$ControllerConfig.(ConfigXMLReader.java:170)
org.ofbiz.webapp.control.ConfigXMLReader.getControllerConfig(ConfigXMLReader.java:132)
org.ofbiz.webapp.control.RequestHandler.getControllerConfig(RequestHandler.java:97)
org.ofbiz.webapp.control.RequestHandler.getDefaultErrorPage(RequestHandler.java:647)
org.ofbiz.webapp.control.ControlServlet.doGet(ControlServlet.java:239)
javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
org.ofbiz.webapp.control.ContextFilter.doFilter(ContextFilter.java:270)

note The full stack trace of the root cause is available in the Apache Tomcat/6.0.26 logs.
Apache Tomcat/6.0.26

It’s amazing that a simple hack posted by someone in 2011 worked for me! After modifying ConfigXMLReader.java as mentioned in the forum post, be sure to recompile opentaps by running the ant command. Don’t have ant installed? Read this.

Posted on 2 Comments

Sencha Touch: Accessing a remote API that is under Basic Authentication

ST makes it pretty straightforward to access webservices or APIs through its various data proxies and Ext.Ajax. But consuming an API protected under basic authentication can be tricky. Both data proxies and Ext.Ajax provide setUsername() and setPassword() methods, and they work fine on most browsers. But in my experience using these methods, I had big time face-palm moments in case of Safari, iOS, and some Android versions. When these methods are used, an ST app sets the Authorization header AND makes all API requests through URLs formed such as this:

http://user:passwd@www.server.com/api/user/2627

I’m not sure why this is such a big deal for some browsers, but they seem to get confused due to the presence of these two things — Authorization header and user:passwd URL.

The trick to solving the issue is to NOT use setUsername() and setPassword(), and instead set the HTTP headers yourself.

Data Proxies have a headers config.

someModel.getProxy().setHeaders({
	'Authorization': 'Basic ' + btoa(username + ':' + password)
});

Ext.Ajax has a defaultHeaders config.

Ext.Ajax.setDefaultHeaders({
	'Authorization': 'Basic ' + btoa(username + ':' + password)
});
Posted on Leave a comment

Sencha Touch: Third-party plugins and build errors

Nothing beats Sencha Touch when it comes to sheer number of options and versatility in developing for the mobile. ST has truly set the benchmark of mobile development done right with each major release. It has a vibrant user community, and a robust enterprise adoption. But, sadly, although the documentation is good, it sometimes feels a bit incomplete. If it weren’t for stackoverflow and ST’s official forums, it would have been difficult for me to complete some aspects of my recent mobile app project. Coming to the point…

ST recently announced the much awaited grid feature . They call it Touch Grid. On the surface, it looks super-customizable (just like everything else ST) and enterprise-ready. In short, it’s just what everyone was waiting for. Unfortunately, it is not available for free. Touch Grid comes as part of the Sencha Touch Bundle, something only suited to the enterprise due to its staggering $695 cost.

A couple of months ago, I was looking for something like Touch Grid for my app. The exorbitant pricing of ST Bundle compelled me to look for free alternatives. That was when I found Ext.ux.touch.grid. Its last release was well over a year ago now, and was tested with ST 2.2. But it still works with ST 2.3 (the current release). Including its source folder “Ext.ux.touch.grid” in the root of my ST app and adding a reference to it in my app.js was all that was needed to get it to work.

When I built my app for production deployment (sencha app build production), I got this error:

Unknown definition for dependency: Ext.ux.touch.grid

The above error basically pops up because of not adding a dependency (say, a plugin) in your ST app’s classpath. Adding it to the classpath resulted in the yet another error:

com.sencha.exceptions.ExBuild: java.lang.IllegalArgumentException

A small tweak fixed this error: I created a new folder “plugins” in the root of my app and moved the “Ext.ux.touch.grid” folder into it. I edited my app.js to change the plugin’s path, and likewise changed the classpath.

Add this to the top of app.js (before Ext.application declaration):

Ext.Loader.setConfig({
    enabled: true,
    paths: {
        'Ext.ux.touch.grid': './plugins/Ext.ux.touch.grid'
    }
});

And add the “plugins” folder to the app’s classpath (edit .sencha/app/sencha.cfg):

app.classpath=${app.dir}/app.js,${app.dir}/app,${app.dir}/plugins

Now build again, and all should be fine!
Happy coding.