In order to take advantage of HTML5’s History API, the application must ignore the URI in the http request and resolve to the root – otherwise you’ll get a 404 error. This can be an issue with a WordPress application because WordPress uses a similar technique by using either Apache or NGINX to resolve all requests to index.php, which then parses the URI and renders the corresponding page/post/archive/ect.
Instead of sending giant payloads or screenshots, send a cURL. From Chrome’s Networking console, simply right click the request and select “Copy as cURL”. Now your colleague can see the exact response you are without going to the browser.
We are proud to introduce React Serial Forms, a module which makes creating forms in large and medium scale applications easier. Check it out here and please feel free to contribute!
We even put together a snazzy example to see it in action.
When we started Lev two years ago, we faced a decision that companies and organizations of all stripes need to deal with — deployments. There is a seemingly infinite number of setups but, in our view, all options seem to fall short in one way or another. When putting together a wish list for our ideal automated deployment solution, here’s what we came up with:
- Manage config files in one place for applications. (Environment specific files like wp-config.php, production.rb, ect.)
- Securely maintain both our open source and our client’s deployments under one roof. No need to mess with a configuration files or connecting wires for each new project.
- Deploy to any SSH-capable Linux server, including shared hosting environments.
- Parallel multi-server delivery.
- Repository-specific deploy keys. Ideal for Git providers that require unique deploy keys. In our case, GitHub and GitLab.
- Post-deployment commands for building/compiling our applications right on the server. Useful for building docker images, compiling assets or restarting services.
- Incredibly fast and secure file migration with only SSH (not relying on FTP or FTPS).
- No server dependencies needed for deployment. Not even Git.
- The ability to intelligently deploy while respecting the .gitignore file so nothing gets blown out.
So we took it upon ourselves to write a low level node.js script which handled Git post-receive payloads. After some tweaking it worked great. Success, right? Well, almost. We had achieved our goal of automated deployments, but the solution was cobbled together using too many tools and providers, and fell short of the all-in-one-place requirement. We needed to manually configure a post-receive hook in whatever repository we were deploying (GitHub or GitLab), and for post-commands we needed to create one-off bash scripts. Not ideal. We needed a user interface.
Many hours of development later, Stackahoy was born.
We now use Stackahoy for all deployments (including Stackahoy itself) and we’re inviting you to check it out for free.
npm is an incredibly handy development tool. Allowing for breaking your projects up into separate modules keeps logic isolated, maintainable and composable – especially when working with a larger team. When working with proprietary software, we can supply specific URLs in the package to lock down permissions and keep the code out of the public npm registry. However, this can cause a problem when working with portable docker images as the git clone will fail due to a missing id_rsa.
The solution we’re using is quite simple. Provide an ssh id_rsa file to authorize the clone. Instead of using your personal id_rsa, it’s much more appropriate to create one specific for the application and then add the id_rsa.pub as an authorized deploy hook in your git provider. This way you don’t have someone’s actual id_rsa floating around in repositories. Here are the steps:
The past few days I’ve been working a lot with Docker. As with many powerful tools, there are quite a few ways to get the job done. The most esoteric of them being how to persist data within Docker’s containers. From bind-mounting directories to your local system, to spinning up containers with only one purpose in life – storage. Here I’m going to be discussing and experimenting with a slightly different way of handling the issue: Controlled Persistence.
Quite a few of our projects are built on top of WordPress. One of the side effects to having a great community of developers behind the CMS is that there are updates almost every week for the core and some of the more popular plugins. Each of our projects is versioned using Git, naturally, so manually dealing with these updates can be quite tedious. So how can we make our lives easier? Well, a command-line script would be nice. There are a few of these that exist. From shell scripts to a fully fleshed out PHP WP package manager. The problem with these is that they are made to work in a similar way the built-in WordPress updater works – update on the server, thus making the staging/production code out of sync with the repository. These scripts also use the database itself to get information about the website via the wp-config.php script. What if you don’t have a local database setup for the project?
This is the reason we wrote this little bash script which handles updating the core and all plugins without the need for a database, wp-config file or a domain name in one fell swoop. Checkout the open source project here on GitHub for more information.
So you just finished developing your node.js application and you’re ready for the world to use it. Congrats. Now it’s time to decide how to host the application. In many cases you would use a turnkey cloud solution like Heroku, OpenShift, or AppFog. These are great services, but what if you want to keep this in-house or you don’t want to shell out the dough for each resource separately? These costs can really add up, even with a non-resource intensive application. Today I’m going to talk about a production-ready boilerplate stack for serving node.js applications from a bare Linux (Ubuntu distro) install.
In the midst of planning an upcoming project, we decided to do a little spec work for a proof of concept. The result was a pretty interesting real-time crime map using data provided by the DC government and the Google Map API. Based on the day you visit, the types of crimes that appear may change, as the data is populated dynamically by DC. Click the map below to play around.
I’ve been maintaining the super simplistic Rye starter theme for WordPress for about 3 years now. Since the time it launched it has been the only theme I have used and recommended because of its minimalistic nature. While there has been some other very well built themes to come out since, I believe they all share the same problems: