On the TutsPlus.com site they've posted a tutorial for those new to PHP and MySQL out there sharing the basics of CRUD operations using the built-in language functionality ("CRUD" stands for "Create, Read, Update, Delete").

In this article, we're going to explore how you could use a MySQL database to perform CRUD (create, read, update, and delete) operations with PHP. If you want to get your hands dirty with database connectivity in PHP, this article is a great starting point.

If you are just getting started with PHP, you probably realize that database connectivity is an essential feature that you'll need to get familiar with sooner or later. In most cases, a database is the backbone of any web application and holds the data of the application. So, as a PHP developer, you'll need to know how to deal with database operations.

In this article, we'll keep things simple and explore how to use the core mysqli functions. In upcoming articles of this series, we'll explore a couple of other ways to handle database connectivity.

They then walk you through some of the basics of:

• creating the connection to the database
• selecting information from the database
• inserting and updating records
• how to pull the record information
• deleting records from the database tables

Each item on the list comes with plenty of explanation and example code to get you on the right path to learn these basic concepts.

On the RIPSTech.com site they've posted a warning to the WordPress users out there about a vulnerability that would allow a malicious user to delete any file in the WordPress installation, not just file uploads.

At the time of writing no patch preventing this vulnerability is available. Any WordPress version, including the current 4.9.6 version, is susceptible to the vulnerability described in this blogpost.

For exploiting the vulnerability discussed in the following an attacker would need to gain the privileges to edit and delete media files beforehand. Thus, the vulnerability can be used to escalate privileges attained through the takeover of an account with a role as low as Author, or through the exploitation of another vulnerability/misconfiguration.

The post includes more details around the impact of the issue and where in the code the problem lies. It also offers a temporary "hotfix" as a way around the issue by adding a new filter that uses the basename function to reset the thumbnail data.

The SitePoint PHP blog has a new post today helping the users of the OctoberCMS content management system build a "soft delete" plugin by extending the functionality already included in the code.

Developers usually stick with a new CMS for its simplicity and extensibility. OctoberCMS presents itself as a back to basics CMS, and provides an enjoyable experience for both developers and users. In this article, I’m going to demonstrate some aspects of the CMS that make it extensible, and we’ll also try a simple plugin to extend another plugin functionality.

The tutorial starts by talking about extensibility and how plugins play into it in most normal CMS software (in their example, its listening to an event fired when a new post is made). They start by creating a new plugin skeleton via the "create:plugin" artisan command and creating a migration to extend the database with the "soft delete" column. After running the migration, they add in a new listener for an "extendColumns" event and extending the filter to extend the scopes pulling out posts data. They further extend the functionality with a helpful trait filtering the data by the "deleted_at" value and adding that into the scope as well. Finally they add a listener onto the Eloquent events for the "deleting" event to capture it and set the "deleted_at" value on the post record and save it.

The SitePoint PHP blog has posted an introduction to using Elasticsearch in your PHP applications. In it author Wern Ancheta covers some of the basics of this powerful tool and helps you get an example script up and running for testing.

In this tutorial, we’re going to take a look at Elasticsearch and how we can use it in PHP. Elasticsearch is an open-source search server based on Apache Lucene. We can use it to perform super fast full-text and other complex searches. It also includes a REST API which allows us to easily issue requests for creating, deleting, updating and retrieving of data.

He starts by helping you get Elasticsearch itself installed via the apt-get package manager (may slightly differ depending on your OS of choice) and tested with a simple web-based request to the port the server is running on. With the server set up he then moves on to the PHP aspect, helping you get the elasticsearch library installed via Composer and creating a new client instance. He then includes code examples of some of the main operations you'll perform with entries in the Elasticsearch instance: inserting a document, updating a document, deleting and - of course - searching for documents matching certain simple and more complex criteria.

In his latest post Mathias Verraes poses the question of how much testing is too much? At what point does testing actually become less useful and how much you really need.

Figuring out how much unit tests you need to write, can be tricky, especially if you are new to Test-Driven Development. Some teams strive for 100% code coverage. Some open source projects even announce their test coverage on their GitHub profiles – as if coverage is an indicator of quality. Coverage only measures the lines of code that are executed by the test suite. It doesn’t tell you whether the outcome of the execution is actually tested, let alone how valuable that test is. Because of that, code coverage of your entire code base is a pretty lousy metric.

He suggests that the "it depends" answer to "how much testing is enough" question just isn't good enough. He puts most of this in the context of TDD (where testing is built-in to the development time) but some of the thoughts could apply to post-code testing as well. He also talks about over-design and how it relates to refactoring with deeper insight. Finally, he talks about a subject not mentioned much in testing articles - when to delete tests.

David Makin has posted the second part of his series looking at creating a simple REST API with the help of Silex. You can find part one here to get caught up.

In part 1 you installed Silex and setup 2 routes, / and /{stockcode}. Now lets expand upon those by adding a POST and a DELETE route. The 2 routes we created use GET but to make your application truly useful you will want to use at least 1 more type and that is POST.

He starts by adding a new POST route to handle the creation of a new "toy", complete with a correct response of a 200 code (HTTP for "created"). He follows this with a DELETE example, showing how to return a 204 if the delete works or a server error if something goes wrong. He also includes a curl call to test out the endpoints. In the upcoming third part David will look at breaking up the code a bit and putting it into separate files.

Lee Davis has a new post to his site with some thoughts about RESTful APIS and the correct response to DELETE calls when a resource has already been removed. One camp says a 404 should be thrown as it's no longer there, the other says 204 a "No Content" should always be returned. Lee looks at both sides of the argument and shares some of his own thoughts too.

Recently I had a read of an interesting post by Lukas Smith (@lsmith) about the use of the DELETE method when building RESTful services. I wanted to get my thoughts down on this. Mostly to help myself, but if it helps you determine a better approach, then great. I’m nowhere near qualified enough to preach, so this is by no means a “you should do it this way / my way is correct post”, just food for thought. Besides, there are probably more questions here than answers.

He talks about the idea of "idempotence" when it comes to REST APIs and how it relates back to the DELETE discussion. He points out that the term has more to do with the end result of the request and not so much about how it's handled (and any "side effects" that may come with it). Various checks on the resource in question - like "does it exist" - could be considered a side effect of its operation. In his opinion, though, the 200 series of responses are more appropriate when a resource is actually deleted.

PHPMaster.com has published the second part of their series taking you on a tour through PHP's IMAP extension and its use. In part one they introduced the extension and showed how to connect, get the folders/emails and view message contents. In this part they expand n that and show you how to work with the messages and attachments.

In the first part of this series I discussed how to connect to IMAP servers using PHP’s IMAP extension. In this part we’ll complete the series by discussing working with folders and reading email content. Let’s get started!

He shows how to work with the "flags" set on messages (read, unread, replied, etc) - pulling them from the server and using the imap_setflag_full function to set them. There's a quick mention of deleting messages with imap_delete/imap_expunge and a section on viewing and downloading the attachments to messages.

Continuing on with his webcast series looking at using the Slim microframework to create a RESTful web service with JSON Output, John Lebensold takes the code from the previous tutorials (part one, two, three) and adds handling for DELETE to remove values from the data.

This tutorial will show you how to add jQuery RESTful calls for using the DELETE verb when deleting items via a JSON REST interface.

You'll definitely need to check out either the previous tutorials in the series to follow along with the code or grab the current source to see how everything's structured.

On SpeckBoy.com there's a new tutorial posted that introduces you to the concept of CRUD - Create, Read, Update, Delete - in the database interface for your application. Technically CRUD can be applied to any sort of data store, but they chose to go with a MySQL-based example.

It has become a common necessity for website owners to collect data and manage it properly. Creating a MySQL CRUD class allows you to conveniently create, read, update and delete entries for any of your projects, indifferent of how the database is devised. CRUD allows us to generate pages to list and edit database records. So, in this tutorial I will show you how to build a simple CRUD web app, that will empower you with the basic functions of database management.

They briefly walk you through the setup of a XAMPP server to use as a base and give you the settings needed to create a simple users table. The rest of the post is the code you'll need to make the connection from your PHP script, insert data into the table, update them, remove the rows and display their contents. They've wrapped it all up in a single "index.php" file to make it simpler.