Month: September 2014

http://blog.chenchatech.com/2014/09/integrating-laravels-auth-with-sentinel/ or even http://blog.chenchatech.com/integrating-laravels-auth-with-sentinel/ or http://blog.chenchatech.com/jacob/integrating-laravels-auth-with-sentinel/ depending on the scheme you choose in your permalink settings.

You may need to process this link to get the actual post id. Say if you are.

Building an API

Redirecting traffic

Using XMLRPC http://codex.wordpress.org/XML-RPC_WordPress_API

Writing out an entirely new interface for wordpress.

Good news is that if you have access to the database on which the wordpress installation runs from, this is relatively trivial.

The only part you need to parse is the post name in our case integrating-laravels-auth-with-sentinel Do a lookup on the wp_posts table post_name column and presto you are done.

User authentication & authorization system is a common use case in a lot of apps. Thankfully Ryan Durham has a package that bootstraps resources needed for a fully functional authorization system in Laravel. You can install the package from packagist

I will not go into details on how .gitignore works the docs http://git-scm.com/docs/gitignore cover it quite well, in summary the file specifies what files git should ignore.

If you are wondering what files to ignore, here are some clues.

IDE Meta Files

Almost all IDEs generate a special folder in your project to store the projects meta data. An example would be the nbproject folder for netbeans.

The entire directory needs to be ignored.

Images, Videos, Documents and other binary files

This are generally user generated contented and not code. Version controlling this assets will lead to unnecessary bloat.

Furthermore if you use github there are limits to the size of the files https://help.github.com/articles/what-is-my-disk-quota .

External Libraries

Libraries that you use for your system an example would be the vendor folder automatically generated by composer https://getcomposer.org/ need to be ignored.

While this libraries are code, you did not write the libraries and have no reason to version it. If you are deploying using git then you can just as easily upload the libraries or run composer update on the remote server and get the same files once more.

Application Output

Unless in edge cases you should never version the output of your code. eg CSV reports, logs, pdfs etc

This is because the data can be easily regenerated and even more importantly it is not part of your code.

Database

If you are using a file based database system like SQLite. Make sure to ignore the database files. If you need a backup. You can setup automated backups separately.

In conclusion you can use this as a general rule of thumb

If you did not write it, don’t version it

Have any extra additions of your own? Please add to the comments section below.