Berdir

<?php

  /**
   * Minifies and removes unneeded cache tags.
   *
   * @param array $cache_tags
   *   List of cache tags.
   *
   * @return array
   *   Shortened and cleaned up cache tag list.

larowlan

My thoughts on core process and roadmaps

Prelude

Much of what is proposed here is a large shift from Drupal's traditional feature addition process which has been largely informal. In the past because of our long release cycles consideration of such a process would have been foolish and this degree of formality would only have discouraged involvement. Now that we're moving towards semantic versioning, the release of Drupal 8 and a move to regular six-monthly minor releases means we're now in a position to consider this kind of formal process. Its a sign that we're maturing as an open source community. Parts of the process, in particular the voting, are modelled on other successful open-source projects that have the same level of maturity as ours. The thoughts proposed here are just that, thoughts. They've been influenced by core conversations at Drupalcon Amsterdam as well as a significant twitter thread on the topic. Please read the whole thing before comme

kacinskas

# swith to sudo
sudo -i

# create swap
touch /2GiB.swap
chattr +C /2GiB.swap
fallocate -l 2048m /2GiB.swap
chmod 600 /2GiB.swap
mkswap /2GiB.swap

mundry

OUTPUT_DIR := build
SOURCES_DIR := styles
DEPS_DIR := .deps

RM := rm -rf
RUBY := ruby
SASS := scss
SASS_OPTIONS := --unix-newlines
SASS_OPTIONS += --style compressed
SASS_OPTIONS += --precision 8

magnetikonline

Nginx FastCGI response buffer sizes

By default when Nginx starts receiving a response from a FastCGI backend (such as PHP-FPM) it will buffer the response in memory before delivering it to the client. Any response larger than the set buffer size is saved to a temporary file on disk.

This process is outlined at the Nginx ngx_http_fastcgi_module page manual page.

• Introduction
• Determine actual FastCGI response sizes
• Setting the buffer size
• Verifying results

lox

SASSC     = sass --style compact
COMPSDIR  = resources/assets/components
SASSDIR   = resources/assets/css
JSDIR     = resources/assets/js
DISTDIR   = web/dist
CSSDIR    = $(DISTDIR)/css
SASSINC   = $(SASSDIR) \
	$(COMPSDIR)/asimov/src/scss \
	$(COMPSDIR)/asimov-contests/src/scss \
	$(COMPSDIR)/asimovicons/src/scss

sun

<?php

/**
 * This gist is no longer maintained - it is a proper repo now:
 *
 * @see https://github.com/sun/drupal-reinstall
 */


#  ██╗    ██╗██████╗  ██████╗ ███╗   ██╗ ██████╗ 

sdboyer

<?php

/**
 * @file
 * Contains \Drupal\Core\Asset\AssetGraph.
 */

namespace Drupal\Core\Asset;
use Gliph\Graph\DirectedAdjacencyGraph;

geerlingguy

<?php

/**
 * @file
 * Generate rules for Drupal Coding Standards Sniffs.
 *
 * SonarQube requires manually-entered PHP CodeSniffer rules if you use anything
 * outside of the standard set of rules. In this case, there are a bunch of
 * Drupal-specific sniffs that we'd like to use.
 *

nikic

Why objects (usually) use less memory than arrays in PHP

This is just a small post in response to [this tweet][tweet] by Julien Pauli (who by the way is the release manager for PHP 5.5). In the tweet he claims that objects use more memory than arrays in PHP. Even though it can be like that, it's not true in most cases. (Note: This only applies to PHP 5.4 or newer.)

The reason why it's easy to assume that objects are larger than arrays is because objects can be seen as an array of properties and a bit of additional information (like the class it belongs to). And as array + additional info > array it obviously follows that objects are larger. The thing is that in most cases PHP can optimize the array part of it away. So how does that work?

The key here is that objects usually have a predefined set of keys, whereas arrays don't: