Dieter Stinglhamber has a new tutorial posted to his site showing you how to build a Laravel application that doesn't use cookies...well, any cookies that could be used for tracking.

Since May 25th you have been harassed by "We have updated our privacy policy" emails but also websites started to great you with "Please, let us and our 256 partners track you".

In response to these abusive practices, some developers have decided to follow a better path, removing every cookie that is not needed. For example, my website doesn't have a single cookie, Spatie new website won't have any either. [...] I encourage every developer to do the same and if you are using Laravel, here's how you can (very) easily get rid of the default cookies set by the framework.

He talks about the two cookies that are used by default in Laravel applications: the CSRF token and the session ID. He shares ways to remove each of these cookies (if you're not using them) and, for a final "trick", removing other cookie-related middleware from the "web" group that interact with cookies.

In a new tutorial on his site Matt Stauffer shows how to remove the Vue.js dependencies from a standard Laravel installation. There's only a few but they're installed by default and if you're not using Vue.js they can easily be removed.

The recent versions of Laravel have come with some very minor Vue dependencies out of the box. They're easy to remove, but you may have not actually tried that yet, or you might be worried you're going to leave something sitting there. So, here's a quick tip on how to remove all Vue dependencies in a new Laravel install in a few easy steps.

The process is broken down into a few steps:

• Install Laravel
• Drop Vue from package.json
• Drop the bootstrap and the sample component

The changes you'll need to make to the configuration files are included so the removal process is pretty painless.

Christian Weiske has a quick tip posted to his site for those using phar archives in PHP and how to remove the .phar extension and still have them execute correctly.

I'm shipping a new side project as .phar file, php-sqllint.phar. The phar stub has a shebang line so that I can call it without explicitly running PHP. [...] When making the file executable with chmod +x, you can simply execute it.

He wanted to remove the extension but was greeted with an error message when he tried to execute the result. He stumbled on the solution in this PHPUnit bug and corrected the problem with a call to the Phar::mapPhar method inside the phar archive file.

The official PHP.net has posted their PHP 7 migration guide for those already on PHP 5.6.x and wanting to prepare their applications for PHP7.

Despite the fact that PHP 7.0 is a new major version, efforts were put in to make migration as painless as possible. This release focusses mainly on removing functionality deprecated in previous versions and improving language consistency. There are a few incompatibilities and new features that should be considered, and code should be tested before switching PHP versions in production environments.

The guide includes links to other pages showing things like:

• Backward incompatible changes
• New features
• Deprecated features in PHP 7.0.x
• New functions/classes/interfaces/global constants
• Removed Extensions and SAPIs

There's also a link to some other various changes that's not completely fleshed out yet, but is evolving as PHP 7 gets closer to a final release.

On the SitePoint PHP blog today Bruno Skvorc has written about the PHP 7 revolution and some of the changes coming with this next major version of the language (including return types and the removal of some functionality).

With the planned date for PHP 7’s release rapidly approaching, the internals group is hard at work trying to fix our beloved language as much as possible by both removing artifacts and adding some long desired features. There are many RFCs we could study and discuss, but in this post, I’d like to focus on three that grabbed my attention.

He touches on a few topics in the post including:

• the debate that came up about PHP 5.7 versus PHP 7
• The addition of return types from functions/methods
• The removal of PHP4 style constructors
• Changes to the extension API

Obviously, since PHP7 is no where near release status, all or some of these things could be subject to change. For example, the removal of PHP4 constructors is still being hotly contested on the php.internals mailing list at the time of this post.

There's been some rumors floating around about the possibility of PHP's MySQL support going away in upcoming versions of the language. In his latest post Johannes Schlüter tries to bring a bit of clarity to these rumors and what's actually being removed.

Over the last few days different people asked me for comments about PHP dropping MySQL support. These questions confused me, but meanwhile I figured out where these rumors come from and what they mean. The simple facts are: No, PHP is not dropping MySQL support and we, Oracle's MySQL team, continue working with the PHP community.

He suggests that the confusion might have come from the recent changes to "soft deprecate" the oldest ext/mysql functionality and warn users against using it in their applications. He talks about the history of MySQL support in PHP and one project that removing it could adversely effect (WordPress).

On Script-Tutorials.com today there's a new article introducing you to using APC caching in your PHP applications. Their simple example sets up a caching class that handles the dirty work for you.

Today I have another interesting article for PHP. We will talking about caching, and practice of using caching in php. I will make review of APC caching and will show you how you can use APC in PHP. [...] Now people have learned to use the server memory for data storage. RAM much faster than hard disk, and the price of memory falls all the time, so let’s use all these advantages of this.

Included in the post is the code for a few different files - the caching class itself that implements the APC functions in PHP and some examples of it in use: saving objects, fetching data from the cache and removing things from the cache.

Stefan Koopmanschap has a quick post to his blog with a handy, not immediately obvious tip for the Symfony users out there - how to remove site-wide stylesheets in a Symfony application so it's not loaded automatically.

Today I encountered a situation I've not encountered before: I have a project-wide stylesheet that should be used for everything, except one specific module that has different (brandable) stylesheets. I created a view.yml for this module with a different stylesheet, but of course the configuration files are merged so it doesn't actually overwrite the main stylesheet file. And this wasn't really what I needed here.

His technique involves a change to the main view.yml configuration file with a special syntax to remove the CSS file with a negation. A snippet is included to illustrate. You can find out more about view configuration in this chapter of the "Definitive Guide to Symfony".

On DZone.com's Web Builder Zone Giorgio Sironi has posted a few methods you can use to help get rid of getters and setters in your OOP PHP applications.

Encapsulation is (not only, but also) about being capable of changing private fields. If you write getters and setters, you introduce a leaky abstraction over private fields, since the names and number of your public methods are influenced coupled to them. They aren't really private anymore:

To show his alternatives, he uses a sample "User" class with a whole list of private properties. There's initially a get/set for the nickname and password values, but he suggests a few replacements:

• passing values in through the constructor
• using the "Information Architect" pattern to have the most responsible method handle the value setting
• the "Double Dispatch" method that uses dependency injection
• using the Command pattern and changesets of data

He also briefly mentions the Command-Query Responsibility Segregation (CQRS) method, but doesn't have any code example to go with it.

Johannes Schluter has a quick new post to his blog today talking about parts of the sqllite extension that will be dropped from the core - the current sqlite_* methods and the pdo_sqlite driver.

The issue there is that this depends on the SQLite 2 library which isn't supported by upstream anymore for a few years. It was a logical step therefore to remove this extension from PHP trunk. The support for the sqlite3 extension and the PDO_sqlite driver (same link as above, read it carefully), which use version 3 of the library, are continued.

The change probably won't be happening in any of the PHP 5.3.x releases but should becoming in PHP 5.4 so, as he advises, you might need to rebuild your database file and change your application to correct things for the changes.