Cordova / Phonegap ios emulate results in a black screen in simulator — SOLUTION

Problem

Trying to get Cordova to run the simulation of the default sample hello world app you type:
cordova emulate ios

At this point the emulator ran and the simulation was merely a black screen inside the simulator window. After a while the following error eventually was displayed in the console:

The Error

Session could not be started: Error Domain=DTiPhoneSimulatorErrorDomain Code=2 "Simulator session timed out." UserInfo=0x7fd5848179d0 {NSLocalizedDescription=Simulator session timed out.}

Error: /Users/XXXX/XXXX/platforms/ios/cordova/run: Command failed with exit code 1
at ChildProcess.whenDone (/usr/local/lib/node_modules/phonegap/node_modules/cordova/node_modules/cordova-lib/src/cordova/superspawn.js:135:23)
at ChildProcess.EventEmitter.emit (events.js:98:17)
at maybeClose (child_process.js:743:16)
at Process.ChildProcess._handle.onexit (child_process.js:810:5)

Solution

To fix this I reset the permissions on the project directory by right clicking the project directory, clicking “Get Info”, clicking the lock to allow access to edit the settings, selected the “Gear” dropdown and selected “Apply to enclosed items…”. This successfully solved the problem for me so that re-running the emulator with works now.

Websockets not working on Elastic Beanstalk with NodeJS when using nginx as a proxy

Amazon Web Service’s default nginx configuration does not have websocket support enabled by default. I am running SailsJS with Socket.io on NodeJS with the default nginx proxy and discovered that websockets were failing to connect. Creating a directory named .ebextensions in the root of my application and a file named 01_files.config within it with the configuration below solved the problem as it instructs nginx to pass websockets through. Just drop this in, deploy your app, and you should be good to go with your websockets functioning.

.ebextensions/01_files.config contents:


files:
    "/etc/nginx/conf.d/websocketupgrade.conf" :
        mode: "000755"
        owner: root
        group: root
        content: |
             proxy_set_header        Upgrade         $http_upgrade;
             proxy_set_header        Connection      "upgrade";

I searched high and low for a solution to this problem and after finding several similar but functioning solutions I combined them to get the above.

Deploying first SailsJS node.js app to DigitalOcean using Dokku on Mac

Here’s a (very) quick and dirty overview of the steps. Follow everything below in order and you should have your node.js app (optionally running SailsJS) deployed on a dokku server on DigitalOcean within a few minutes.

Useful Links:
* Dokku – https://github.com/progrium/dokku
* MariaDB plugin – https://github.com/Kloadut/dokku-md-plugin


Set your SSH key into DigitalOcean if you haven’t already
* cat ~/.ssh/id_rsa.pub | pbcopy
* Paste this key into digitalocean control panel.


Create Droplet

* Select 1GB
* San Fran
* Dokku
* Select your existing SSH key.
* Virtio + backups (maybe virt network if need to connect)


Set up Dokku

* Visit in your browser: http://YOUR-SERVER-IP/
* Submit, optionally setting the app URL to use subdomains. Most settings should default to correct at this point.

Initialize the app access dokku

* cat ~/.ssh/id_rsa.pub | ssh root@YOUR.DROPLET.IP.ADDRESS "sudo sshcommand acl-add dokku YOUR-APP-NAME"
** Note that if instead of YOUR-APP-NAME you put a full domain it will use that as the URL instead of setting up a subdomain. Eg api.dustinbolton.com instead of dustinbolton-api


Configuring local app

Initialize the local repo if you have not already
* git init && git add -A && git commit -m "Initial commit"

Assign production (or staging) destination:
* git remote add production dokku@YOUR.DROPLET.IP.ADDRESS:YOUR-APP-NAME

Create file to tell server what to run on deployment:
* touch Procfile && open Procfile
* Add the following into this new file & save:
* web: sails lift
** For non-sails framework, instead of “sails lift” this would be “node app.js”.


Deploy & launch the app

* git push -u production master
<3>Done!


If you need to manually re-run the app or see the output of the run attempt (such as to troubleshoot):
* ssh root@YOUR.DROPLET.IP.ADDRESS
cd /home/dokku/YOUR-APP-NAME
dokku run YOUR-APP-NAME sails lift
(or instead of “sails lift”, “node app.js”)


Adapted from the guide at:

http://matthewpalmer.net/blog/2014/02/19/how-to-deploy-node-js-apps-on-digitalocean-with-dokku/


MariaDB (mysql drop-in alternative) plugin:

cd /var/lib/dokku/plugins
git clone https://github.com/Kloadut/dokku-md-plugin mariadb
#git clone https://github.com/musicglue/dokku-user-env-compile.git user-env-compile
dokku plugins-install


Create Database Instance

dokku mariadb:create YOUR-APP-NAME
* This creates the mariadb instance and links it to your app automatically since the name matches. The database name is “db” by default.

You can use the credentials displayed or access them via environmental variables such by: process.env.DB_USER


Setting Custom Environment Variables

Database environment variables should automatically exist but I have seen them drop off. I have not found the cause yet and have decided to manually set the one(s) I need for the time being.
dokku config:set YOUR-APP-NAME DATABASE_URL=whateverhere


If you ever need to restart your app. Only change “YOUR-APP-NAME”:

docker restart `cat /home/dokku/YOUR-APP-NAME/CONTAINER`

Programmatically submitting an HTML form via jQuery submit() or trigger(‘submit’) doesn’t work? Solution!

Say you are trying to submit an HTML form via jQuery. If you’re trying to submit it using .submit() or .trigger(‘submit’) you may have ran into a very strange problem where nothing happens for no reason you can figure out. Here is a very basic example below. Why on Earth is this not working?


<script type="text/javascript">

jQuery('#my-form-submit').click( function(e) {
 e.preventDefault();
// Do some stuff here...
jQuery( '#my-form').submit();
 });

</script>

<form action="?ajax=4" method="post" id="my-form">
 <input type="submit" name="submit" value="Submit this form!" id="my-form-submit">
</form>

 

Browsers reserve some key words for input names, such as “submit”. As you see in line 12 we have name=”submit”. This simple thing is the problem. Just change name=”submit” to name=”my-submit”:

Does not play nicely with jQuery triggering of submit:


 <input type="submit" name="submit" value="Submit this form!" id="my-form-submit">

Works:


 <input type="submit" name="my-submit" value="Submit this form!" id="my-form-submit">

Unfortunately browsers offer no error or exlanation to the developer as to why triggering the submit is not doing anything. This can be quite frustrating until you figure this tiny aspect out.

Error: ER_NO_DB_ERROR: No database selected

For me this was caused by using the adapter type of ‘sails-mysql’ as the value when setting up the adapter instead of my custom name I made for it matching the definition later in the adapters.js file.

Logic error in mySQL ORM.
{ [Error: ER_NO_DB_ERROR: No database selected] code: ‘ER_NO_DB_ERROR’, index: 0 }
error: Hook failed to load: orm (Error: ER_NO_DB_ERROR: No database selected)

“Uncaught exception Fuel\Core\Database_Exception: No MySQLi Connection”

Problem

Upon trying to run some migrations in FuelPHP via command line with Oil I ran into this error message containing the error

Uncaught exception Fuel\Core\Database_Exception: No MySQLi Connection

I discovered that when running from the command line my normal php.ini was not being run. PHP was using the defaults, including the default mysql socket which was in the wrong place.

Solution

In my case I created a symlink to redirect which seems to have done the trick. I am running Mamp on OS X in default locations so your directories may differ.

cd /var/mysql

sudo ln -s /Applications/MAMP/tmp/mysql/mysql.sock mysql.sock

There may be a better fix and this may be a symptom of something else being ‘off’.  I initially created a /etc/php.ini with the proper socket location directive but this did not work out properly, possibly due to permissions or something.

“No input file specified.” with .htaccess on FCGId

In my case I was trying to get PHP playing nicely with my FuelPHP app running on Apache under FCGId configured via Virtualmin.  My .htaccess looked like:

<IfModule mod_rewrite.c>
RewriteEngine on
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ index.php/$1 [L]
</IfModule>

The fix was annoyingly simple and took me hours of digging to discover.  Insert a question mark before the slash after index.php like this:

<IfModule mod_rewrite.c>
RewriteEngine on
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ index.php?/$1 [L]
</IfModule>

Alternatively you can also get it to work WITHOUT adding in the question mark by changing from FCGid to CGI (if configuring via Virtualmin: Server Configuration: Website Options: PHP script execution mode from “FCGId” to “CGI wrapper”) but if you want it to work in FCGid mode you will need the question mark.  I do not know why this is the case though.

FuelPHP unexpectedly returns Arr instead of data accessing REST controller with no format specified

When working with the REST Controller in FuelPHP and accessing it from your browser you see “Arr” when a format is not specified in the URL instead of the expected data in your default format. This is because of a setting in the rest.php config file (fuel/core/config/rest.php OR /fuel/app/config/rest.php).

Change:

<pre>’ignore_http_accept’ => false,</pre>

to:

<pre>’ignore_http_accept’ => true,</pre>

 

This is faster and will make your default the default format as expected.  If the client needs the data in another format they can specify it in the URL.

WordPress options in Standalone vs Multisite ( aka update_option vs update_site_option )

While researching how data needed to be migrated for Multisite functionality in BackupBuddy I’ve had to do a lot of digging into the differences between how options (and other) data is stored and retrieved in Standalone versus Multisite WordPress setups. This was an extremely confusing venture and not intuitive at all. I’ll start with a table of my resulting findings and explain from there. In this example I’m using update_option() and update_site_option(). The same structure is followed for transients and other data as well so this basis should work for you. It is important to note that when in a Multisite environment the terms site and blog are used interchangeably by WordPress core in code and mean the same or entirely different things depending on context. This is an unfortunate failure of WordPress and adds to the confusion.

  update_option update_site_option [global]
Standalone Site wp_options [local (effectively global)] wp_options [global]
Multisite Main Site or Network Admin wp_options [local] wp_sitemeta, site_id (aka network id) set [global]
Multisite Site (non-main site) wp_##_options [local] wp_sitemeta, site_id (aka network id) set [global]

In a Standalone WordPress installation update_option() stores data in the wp_options database table. The update_site_option() function falls back to update_option() when in standalone mode so there is really not much of a functional difference here. This data can be updated / retrieved anywhere in the WordPress installation so it’s effectively global. It’s best to use the proper one though in case the site is ever migrated into a network with BackupBuddy.

In a Multisite WordPress installation things get … weird and non-intuitive. The verbage used by WordPress is very confusing unfortunately. (Individual sites in a Network installation are called Sites — but in code they are often called blogs and you can have multiple blogs within a site (you can technically have multiple blogs within multiple sites within one Network but that’s another story…). Things vary depending on where you are so keep your eye out for this. If you are in the main site dashboard, main site front-end, or Network admin, update_option() will place data in wp_options. Data manipulated while in the Network Admin behaves as if it was manipulated within the Main Site (!). If you are in another of the Network’s site admin/dashboard that is not the main site and not the Network Admin then update_option() stores data in wp_##_options where ## is the ID number of the blog. These options are only available within the respective area. These are `local options`. If at any time you want to set an option that is globally accessible by its name anywhere in the entire network use update_site_option().

Dustin Bolton – Software Engineer, Web & WordPress Developer