The TutsPlus.com site has a new tutorial posted showing you how you can use PHP, jQuery and AJAX together to help make the overall user experience of your application better and more responsive.

Today, we’re going to explore the concept of AJAX with PHP. The AJAX technique helps you to improve your application's user interface and enhance the overall end user experience.

The post starts with an introduction to AJAX - what it is, how it's commonly used and how the normal requests flow. They then show how it works with normal "vanilla" Javascript (no jQuery) and how that compares to the jQuery version. It then dives into the real-world example script, showing how to create a form that sends login information to the backend for evaluation via a POST request.

The North Meets South podcast, hosted by PHP community members Jacob Bennett and Michael Dyrynda, has posted their latest episode - Episode #47: Reinventing form controls, typing ahead, and converting MySQLi to Query Builder

In this new show Jacob and Michael return after a hiatus during the summer to talk largely about accessibility in applications (including forms and the overall UI) and updating the Query Builder to work with MySQLi versus MySQL.

You can listen to this latest episode either using the in-page audio player or by downloading the mp3 of the show. If you enjoy it, be sure to subscribe to their feed and follow them on Twitter to stay up to date on when new shows are released.

On the Jolicode.com blog, there's a tutorial they've posted showing how to "mix security and forms" in a Symfony application to show only certain form fields based on a user's roles.

In some applications, it could be required to disable some form fields depending on user’s roles.

In this article, we will see how to implement this feature thanks to a simple example: a blog engine.

For their example, they use a Symfony 4 application with the MakerBundle and create a basic blog with "article" entities and an "admin" entity for the user list. From there, the post includes the code needed to update the buildForm method in the ArticleType class to check the current user and be sure they have the "admin" role. To make this work, they also build out a SecurityExtension form extension class that performs the actual check. This is then hooked into the pre-submit event on the form to prevent other issues where an attacker might delete the "allowed" element and submit the data anyway. The post wraps up with an example of performing a similar check but hiding the field instead of just disabling it in the form.

In this post to his site Martin Hujer suggests that you don't use entities directly in your Symfony forms, opting instead for custom functionality to persist form data.

Let's start with stating that using entities for validation in Symfony Forms is widely used and widely recommend approach. Even the official documentation suggests it.

And I don't think it is a good idea! Why? [Three reasons:] an entity should be always valid, change [in the future and] layers separation.

For each of these downfalls he gets into a bit of detail about what the issue is and introduces the alternative: a custom data class. This class is then used to represent the data in the form with some simple assertions. He includes an example of this kind of class with three properties: title, content and public date. He then shows how to build a form using this class and how to handle updates, not just creates, with the same functionality.

On the Cloudways blog they've posted a tutorial showing you how to create a simple contact form that emails when someone fills it out and the information they submitted.

Laravel is well known for providing multiple solutions for a problem. This is one of the main reasons of the popularity of the framework. Popular Laravel solutions cover routine functionality such as authentication, sessions, routing, and caching.

Contact Us forms are another routine functionality that is a requirement of more or less every website. In this article, I am going to demonstrate how you can easily create a contact form in Laravel with email. To understand the functionality of Laravel mail function. I suggest you read my previous article on sending emails in Laravel.

The author then walks you through the installation of a new Laravel application on the Cloudways service. He then shows how to install the "Form" package (laravelcollective/html) and enable it as a service provider. Next up comes the database configuration and the creation of the table to handle the data submitted via the "Contact Us" form. The model is then created to work with the table, the route is added to show the form (and handle the submission) as well as the matching view and controller. The post wraps up with the commands and configuration you'll need to send the emails and an example of a "mailable" class to handle the email's construction.

The TutsPlus.com site has posted the third part of their "Dynamic Page Templates in WordPress" tutorial series today. In this latest article author David Gwyer finishes off the series using all that they've shared from part one and part two to create two examples.

In the first two parts of this tutorial series, we covered what dynamic page templates were and why they were needed. We also looked at the code required to implement them.

In this third and final tutorial in the series, I'll be creating two examples of fully working dynamic page templates you can use in your own projects. These were specifically chosen to be easily extendable to suit your own needs, and are intended as inspiration for any other type of dynamic page templates you can think of.

He then walks you through the creation of the two page templates: a Simple Contact Form and a Blog Post Archive. The first allows you to dynamically control the form elements for a UI interface (rather than code) and the second uses dynamic data to display the list of previous blog posts. The tutorial then finishes with a look at how, since WordPress 4.7, you can use dynamic page templates with any kind of post, not just pages.

Michael Dyrynda has written up a new post for the Laravel users out there showing an elegant form handling method he's come up with that doesn't involve the use of the older version of the Laravel Collective HTML package.

On episode 28 of the North Meets South Web Podcast, Jake and I were discussing packages that we always pull into our Laravel projects. Jacob mentioned that he still uses the Laravel Collective HTML package, which was forked from the functionality that was present before Laravel 5, which is something I suggested I hadn't done for a long time.

[...] Jacob went on to explain that a big part of using the form package is because it handles binding form data directly to the forms for you, allowing you to separate form inputs from the create / edit components themselves. [...] I suggested that you can go about this simply enough in your applications by using a combination of the old() helper method and an empty model.

He includes code examples of both ways to generate the form, first using the Collective package then using just the old() helper function to repopulate the form values when the page is rendered. He points out that using this internal method doesn't require yet another package. There are some niceties that are missed with going with the old() method, but there are benefits too.

In a new post to his site Matthias Noback introduces you to a package that can help you in your Symfony-based console application, combining the Form and Console components, to make it easier to create "forms" on the CLI.

About 2 years ago I created a package that combines the power of two famous Symfony components: the Form component and the Console component. In short: this package allows you to interactively fill in a form by typing in the answers at the CLI. When I started working on it, this seemed like a pretty far-fetched idea. However, it made a lot of sense to me in terms of a the package in use, building a "form" that just asks the user to input a name. An image of the result is included as well. He ends the post with some of his other general findings during the process of creating the package and suggests a few common use cases including installation wizards that can be used in both the CLI and web interfaces.

On the DotDev.co site they've posted an article from Talevski Igor about integrating Google's ReCaptcha with Laravel for use in verifying forms and protecting them against automated attacks.

Today i have task to create ReCaptcha on contact form with in a Laravel Web page and I like to share the process of making this possible.

He then walks you through the process of getting the configuration you'll need for your domain and using this package to easily integrate it with Laravel and its forms. He adds the routes for both the GET and POST requests along with the matching view and controller. He then uses the env helper function to get the ReCaptcha key from the configuration and places it in the form. He also adds the "g-recaptcha-response" variable to the required values rules and creates a simple Guzzle HTTP client to make the request back to Google to verify the result.

On the Stovepipe Systems blog Iltar van der Berg shares some thoughts about rethinking form development and how moving from composition over inheritance model can help make working with Symfony forms easier.

In one of my previous blog posts, Avoiding Entities in Forms, I've shown how to decouple your forms from your entities. Afterwards I got feedback and most of it was about the lack of examples and the flow, when to fill your data and how to get this back in the entity. However, often I notice that developers design forms based on their entities. This can lead to complex forms because you're confined to a strict set of properties. Developers often get struck with unmapped fields and form events to work their way around those limitations.

With Symfony Forms I highly recommend to follow the composition over inheritance principle. Small form types are easier to re-use and make it less complex to build forms. Moreover, this allows small data objects to have specific goals with validation for their specific case, rather than complex validation groups.

He starts with an example user story, defining a need for a form that allows users to post comments on blog posts. He starts on this simple form, defining the "bare minimum" the form requires and creating a class/entity to match. He then talks about what happens when the business need changes and they want a checkbox too. Since he created the form based on the "composition" idea (not defined by the database structure) he could pretty easily update it with this new field and add a bit of extra handling.