You probably know that a user should only see his orders, his messages and so on, but should never see others’ data. But it probably happened you forgot at some point to add this little WHERE condition that restricts the user to what he should see, in a Symfony param converter for instance.
I’m going to introduce an elegant and automatic solution to never forget these conditions in all of your queries, whatever the table (i.e. the Doctrine entity), whatever the page in your Symfony application.
To do so, we are going to use Doctrine filters and annotations.
This way, you will enhance security, make your code easier to read (no need to create specific queries) and implementing new features is faster.
localizeddate filter in Twig (in the Intl Extension) formats dates according to the current or given locale.
While you can display dates with the dd/mm/yy / mm/dd/yy / yy/mm/dd formats depending on the locale, it’s not possible to display a 4-digit year like in 31/12/2014 (French style) or 12/31/2014 (US style) or any other format depending on the locale.
This post shows how to implement a Twig extension to display such dates, keeping the localization benefit.
This post presents two simple yet underused Symfony2 features that make actions code shorter and simpler to understand:
- The @Template annotation
- Action parameters conversion (optionally used with the @ParamConverter annotation).
We will see step by step how to simplify a generated CRUD controller to leverage these features.
Doctrine filters will be introduced in an upcoming blog post to make things even easier and more reliable in some use cases.
Just a little tip to count how many rows have been updated after the execution of a Doctrine query.
It’s available on Github at this address: https://github.com/michaelperrin/bootstrap-modal-sheet
I uploaded a demo page so that you can test it: demo page
Symfony2 provides a date validator and a range validator for integers but no range validator for dates.
We’re going to implement one in this post.
We’re going to setup an easy-to-use notification system using jQuery and the Symfony2 event dispatcher, plus some CSS to get things look nice.
What we want to do:
- display a success or fail notification message after an AJAX request has been performed.
- make it totally automatic
How we’re going to do it:
- Backend side:
- Define notification messages in the Symfony application using the Symfony Flash Messages system which is also used for non-AJAX requests
- Use the Symfony Event Dispatcher to automatically add notification messages data to JSON responses.
- Non-JSON responses will use the session to display notifications on the rendered page, as usual
- Frontend side:
- Make a jQuery plugin to display notification in a nice way (animated, display notifications in a stack, Growl-like)
- The same jQuery plugin will listen to all AJAX responses and display related notifications if there are some
It feels a bit strange to dive into symfony 1 code again but I updated today the sfAlohaPlugin plugin that I wrote some time ago to easily integrate the Aloha editor into a symfony 1.x project.
The documentation I provided for this plugin was incomplete to make the plugin work well out of the box and this should be fixed now.
The plugin helps you to turn any HTML block (e.g
<div></div> blocks) into an in-content editable block. Compared to a simple use of the Aloha Editor, it provides some nice features:
- Automatically initialize Aloha Editor parameters
- Save the edited content to the database (its structure is created on plugin install)
- Upload image feature : a plugin for Aloha has been made for this purpose. Images are uploaded to the server.
- Some parameters for the symfony app:
- Only allow connected users to edit content
- Only allow users with specific credentials (like being an administrator) to edit content
- Set default Aloha editor loaded plugins
I also set up a demo environment for the plugin so that you can try it!
Here is the demo address to see it in action: sfAlohaEditor demo
Download and learn more about the project: sfAlohaPlugin on Github
- This plugin embeds Aloha Editor 0.21 while the latest version is 0.22.x. This version introduced a lot of compatibility breaks and fixing the plugin to work with Aloha Editor 0.22.x would take too much time
- I’ve been pretty disappointed by Aloha Editor and wouldn’t choose it as a WYSIWYG HTML editor now. The documentation is not complete at all (and I don’t see any enhancements), the library is huge for a limited set of features, compatibility is broken between versions without any upgrade guide. So for now I would highly recommend to move to CKeditor 4, which has a better documentation and now supports inline editing as well. After considering Aloha integration into Drupal, the Drupal team moved back to CKeditor as well: From Aloha to CKEditor
Despite the abundance of WordPress plugins for inserting source code in a post, I never found any easy solution to edit posts mixing text and code. The need to switch between the WYSIWYG editor and the HTML code editor is pretty cumbersome and indentation always gets broken at some point.
For a tech blog, one of the most suitable ways to write posts is to use the Markdown markup language, which is used for documenting projects among others on Github.
There is a plugin for that: WP-Markdown. Using it, writing posts is made really fast and easy.
However, syntax highlighting is made with Prettify.js which is not very efficient for all languages.
I installed 2 more plugins to get code look better:
To get things working, follow these steps:
- In Settings > Writing, uncheck the Enable Prettify syntax highlighter option
- In Settings > Highlighter, check the Load All Brushes option
And you’re done!