Freek Van der Herten has a new post to his site sharing a method he's worked up to make Nova fields translatable as a part of the functionality provided by the Laravel Nova too.

Laravel Nova is cool package to quickly create admin interfaces in a Laravel app. Unfortunately there's no support for multiple locales out of the box. A while ago we published a package called nova-translatable that makes any of the built in field types translatable.

He shows how to use the package they've developed to store the translations in a JSON column in the related model's database table. He includes screenshots of the interface and code snippets along the way to help you easily integrate this feature into your resulting administration page(s).

On the SitePoint PHP blog today they've reposted an article that was originally posted on the ParagonIE blog about searching encrypted information in database fields from author Scott Arciszewski.

This question shows up from time to time in open source encryption libraries’ bug trackers. This was one of the “weird problems” covered in my talk at B-Sides Orlando (titled Building Defensible Solutions to Weird Problems), and we’ve previously dedicated a small section to it in one of our white papers.

You know how to search database fields, but the question is, How do we securely encrypt database fields but still use these fields in search queries?

Our secure solution is rather straightforward, but the path between most teams asking that question and discovering our straightforward solution is fraught with peril: bad designs, academic research projects, misleading marketing, and poor threat modeling.

They start off with some of the examples of bad ways to perform the searching of encrypted information, mostly around either using poor encryption levels or custom created encryption solutions. With those out of the way, the tutorial moves on to their recommended method: using an authenticated encryption scheme (libsodium) and blind indexing. The key to the method is to use a secondary column for the actual searching process, encrypting the value provided and running the search against that, not the encrypted value itself. The article then covers two questions that need to be asked before putting this method to use. The article ends with a method to enhance the previous searching to allow for "fuzzier" searching through the generation of some additional index values in a joined table.

If you've been around the PHP community (or language) for any amount of time, you've noticed that the mascot for the language is an elephant. Back in the mid-2000s this mascot made a move into the real world and the first blue elePHPants were released as plush toys. Since then several different groups and companies have produced their own versions with their own colors and logos. There's several of them out there and the Field Guide to ElePHPants site lists them all.

The PHP elephpant, Elephpas hypertextus, was first sketched by Vincent Pontier in 1998. For ten years it was only seen in drawings. The plush elephpant was first sighted in 2007. Since that time a large number of variations have been observed in the wild.

The site covers fun facts about their overall appearance, identification of the generations, their "natural habitat" and how they're distributed. They then list each of the elePHPants including pictures, talking about the origins of each and several that are "coming soon" from other groups/conferences. Some of the elePHPants are more rare than others (like the Gold of which only one was produced) but more and more are coming on the scene all the time, usually as a part of Kickstarter campaigns.

The SitePoint PHP blog has posted a new tutorial that's another Drupal-focused article explaining custom Display Suite fields in the latest Drupal 8. Display Suite is a popular Drupal module that's been ported from Drupal 7 to version 8. It provides lots of features to help you easily create these custom fields and integrate them into layouts with other core fields.

Without question, Display Suite is one of the most popular modules in Drupal’s contributed modules history. It allows the creation of layouts, fields and exposes all sorts of other powerful tools we use to build the presentation layer of our Drupal sites.

[...] In this article, we are going to look at how we can create our own Display Suite field in Drupal 8 using the new OOP architecture and plugin system. To demonstrate this, we are going to create a DS field available only on the Article nodes that can be used to display a list of taxonomy terms from a certain vocabulary. And we’re going to make it so that the latter can be configured from the UI, namely admins will be able to specify which vocabulary’s terms should be listed.

He starts with a brief introduction to Drupal 8 plugins and their structure. From there he gets into the creation of the VocabularyTerms class they'll use to define their custom DSField plugin. He goes on to create the default configuration, formatters and how to show a list of the current settings (a summary). He then creates the form where the plugin can be configured through the UI and how to render the resulting field.

The SitePoint PHP blog has posted a new Drupal tutorial about allowing multiple editors to work on the same node of content.

have encountered a practical use case where the default configuration options are not enough. Namely, if you need to have multiple users with access to edit a particular node of a given type but without them necessarily having access to edit others of the same type. In other words, the next great article should be editable by Laura and Glenn but not by their colleagues. However, out of the box, users of a particular role can be masters either of their own content or of all content of a certain type. So this is not immediately possible. In this article I am going to show you my solution to this problem in the form of a simple custom module called editor_list.

He walks you through the process, first creating the .info file needed to define the module and the changes needed for the .module file. He creates a few helper functions to get the editor listing for a node and its matching access rules. With the module created he then gets into building the fields, again making helper methods to get the editors for the fields. Finally he "tidies up" and adds an "Authored on" section to the node editor with a helper function to receive and handle the results of this field when the form is submitted.

The SitePoint PHP blog has a new tutorial posted today showing how to create custom field formatters in a Drupal 8 application. Custom formatters allow you to enhance the current functionality of objects in the application and extend them with additional functionality.

With the introduction of annotated plugins, a lot has changed in Drupal 8. We have a more streamlined approach to describing and discovering pieces of functionality that extend the core. Along with many other components, the former Field API (part of the larger and consolidated Entity API) is now based on plugins. In this tutorial we will go through defining a custom field formatter for an existing field (image). What we want to achieve is to make it possible to display an image with a small caption below it. This caption will be the title value assigned to the image if one exists.

They start with a new custom module, starting with just the YAML configuration. Then they help you create the field formatter as a plugin in the "Plugin/Field/FieldFormatter" namespace (code included). They explain how this code works and show how to add it as a hook to make it available to the template layer. Finally they show it in use and how it places the title value into the image caption in the result.

Evert Pot was seeing some weird issues with his MySQL BOOL usage via PDO when he upgraded to one of the latest versions (5.6). Thankfully, he's shared his solution to the problem as well as the symptoms he was seeing when it was causing problems.

I recently updated my workstation to run MySQL 5.6.13. It didn't take very long for things to start breaking, and since I couldn't find any other information about this on the web, I figured this may be useful to someone else. The main error that started popping up was: "Fatal error: Uncaught exception 'PDOException' with message 'SQLSTATE[HY000]: General error: 1366 Incorrect integer value: '' for column 'my_bool' at row 1' in test.php" This exception happens under the condition that you use PDO, prepared statements and booleans.

He includes a small sample script to reproduce the issue and points out the issue - the default casting of prepared values to strings in prepared statements with PDO bound parameters. He shows two "relatively easy solutions" to the problem - either using integers instead of the true/false PHP boolean or specifying a type with the bindValue call.

Matthew Setter has posted the second part of his look at the HTML5 form support that comes with Zend Framework 2. In this new post, he focuses on a few different fields - month, range, color, week and number.

Owing to the overwhelming popularity of the first post on the new HTML5 fields in Zend Framework 2 here on Malt Blue, it’s only right to have a follow up, covering the other available elements. [...] To really show just how effective using these new elements is, each code snippet had an accompanying screenshot of the element, rendered in iOS on iPhone.

He includes examples for each of the element types including a small screenshot and the code needed to create it. They show how to create the elements and define the custom attributes (like the range for a "Number" field or the date range for a "Week").

Ian Christian has added a new post to his blog today showing how you can create a custom form field type in Symfony 2 by extending the AbstractType.

I am finally starting to dive into symfony 2 properly. Yes - it's taken a while, work has taken me in different directions! I found myself needing to create a custom form field type pretty quickly, but couldn't find much in the way of documentation to do so, so I thought I'ld throw it up here; partly to help others, but mostly to get feedback to make sure I'm not approaching this from the wrong angle.

He includes the code that creates his custom "Person" model and the class to create his "transport type" select box that pulls in its values from a "choice list" class. He registers it in his bundle and it can then be included in his buildForm() method just like any other form field.

On the AjaxRay.com site today there's a new tutorial for the Zend Framework users out there with a library they can use to extend Zend_Form for custom phone number fields.

When taking Phone number as user input, we can worn users about phone number format by setting a hint/description and can validate using Regular Expression. [...] Now, if we try provide this feature in Zend Form, that’s possible. We can create three individual Zend_Form_Element_Text objects and join there value together to make the phone number. But, in this case, validating them together is a hassle.

Instead of separate fields, the library they create makes it simple to handle them as a whole field. It works as a helper for Zend_Form and lets you set things like the separator between the text fields, a "format" string and a validator to apply to their fields (in the example code, it's the "digits" validator). Sample code is included to show you how it fits in your form.