| (function($) { | |
| $.fn.countTo = function(options) { | |
| // merge the default plugin settings with the custom options | |
| options = $.extend({}, $.fn.countTo.defaults, options || {}); | |
| // how many times to update the value, and how much to increment the value on each update | |
| var loops = Math.ceil(options.speed / options.refreshInterval), | |
| increment = (options.to - options.from) / loops; | |
| return $(this).each(function() { |
| $time = microtime(); | |
| $time = explode(' ', $time); | |
| $time = $time[1] + $time[0]; | |
| $start = $time; | |
| // do something in here | |
| $time = microtime(); | |
| $time = explode(' ', $time); | |
| $time = $time[1] + $time[0]; |
| RewriteEngine On | |
| RewriteBase / | |
| RewriteCond %{HTTP_HOST} ^www\.(.*)$ [NC] | |
| RewriteRule ^(.*)$ http://%1/$1 [R=301,L] |
| gem install nokogiri -- --with-xml2-include=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/include/libxml2 --use-system-libraries |
| var saveTranslations = function (el) { | |
| var popupId = '#' + el.attr('id').replace('-', '-popup-'); | |
| el.trigger('click'); | |
| jQuery(jQuery(popupId).find('.term-save')).trigger('click'); | |
| var waitForClose = window.setInterval(function () { | |
| if (jQuery(popupId).text() === '') { | |
| window.clearInterval(waitForClose); | |
| var nextRow = jQuery('#' + el.attr('id')).closest('tr').next('tr'); | |
| if (nextRow.length > 0) { | |
| console.log('next row'); |
| I have changed the way I am doing reverse proxy on Mountain Lion Server. On my old Snow Leopard Server system, I looked at how it set-up Reverse Proxy. Configuring Reverse Proxy from the GUI, in Snow Leopard Server, added the following to the site configuration file (after the <IfModule mod_ssl.c> ~ </IfModule> section): | |
| <IfModule mod_proxy_balancer.c> | |
| ProxyPass / balancer://balancer-group/ | |
| ProxyPassReverse / balancer://balancer-group | |
| <Proxy "balancer://balancer-group"> | |
| BalancerMember http://my.example.com:8080 | |
| </Proxy> | |
| </IfModule> | |
In general for Wordpress the server needs the following:
https://wordpress.org/about/requirements/
In order for us to deploy to the server easily we will need the following as well:
git & composer
# Note the new setup script name for Node.js v0.12
curl -sL https://deb.nodesource.com/setup_0.12 | sudo bash -
# Then install with:
sudo apt-get install -y nodejs
taken from https://nodesource.com/blog/nodejs-v012-iojs-and-the-nodesource-linux-repositories
| // v0.1 | |
| // @saftsaak | |
| // got tt the plugins page, open the developer tools on your browser, paste this, hit enter and then copy-paste the output from the console log | |
| var pList = ""; | |
| jQuery('#the-list tr.active:not(.plugin-update-tr)').each(function () { | |
| var $this = jQuery(this); | |
| var pTitle = jQuery('.plugin-title strong', $this).text(); | |
| var pVersion = jQuery('.plugin-version-author-uri', $this).text(); | |
| var pDesc = jQuery('.plugin-description', $this).text(); |
One of the best ways to reduce complexity (read: stress) in web development is to minimize the differences between your development and production environments. After being frustrated by attempts to unify the approach to SSL on my local machine and in production, I searched for a workflow that would make the protocol invisible to me between all environments.
Most workflows make the following compromises:
Use HTTPS in production but HTTP locally. This is annoying because it makes the environments inconsistent, and the protocol choices leak up into the stack. For example, your web application needs to understand the underlying protocol when using the secure flag for cookies. If you don't get this right, your HTTP development server won't be able to read the cookies it writes, or worse, your HTTPS production server could pass sensitive cookies over an insecure connection.
Use production SSL certificates locally. This is annoying