Using .htaccess to add trailing slashes to all URIs or URLs | Geekology Apache's Rewrite Module allows developers to define extensive URL Rewriting and Redirecting Conditions & Rules, one of which could be to add trailing slashes to Representational State Transfer (RESTful) URLs. RESTful URLs are Uniform Resource Indicators (URIs) that are more user- and SEO-friendly than standard GET-based URIs. For example (GET vs. ...or (GET vs. To use URL Rewriting to add a trailing slash to all RESTful URIs, create a .htaccess file in your website's root folder (if it doesn't exist yet), open it, and add this content: <ifModule mod_rewrite.c> RewriteEngine On RewriteBase / RewriteCond %{REQUEST_FILENAME} ! The RewriteEngine, RewriteBase, RewriteCond, and RewriteRule lines tell Apache to enable the Rewrite Module, set the base directory to the website's root directory, and redirect all requests for non-existant files or directories to the website root directory.
Encoder son site intégralement en UTF-8 Il existe deux méthodes en PHP permettant d'afficher du texte en UTF-8. Après avoir bien sûr encodé correctement tous les fichiers selon la manière décrite juste au-dessus. L'une est radicale au niveau du fichier, l'autre se fait au cas par cas, sur chaque texte à afficher. La méthode radicale consiste à mettre en première ligne de chaque fichier, un header qui va préciser au serveur de renvoyer de l'UTF-8 : header( 'content-type: text/html; charset=utf-8' ); L'autre méthode consiste à utiliser une fonction PHP autour du texte que l'on veut afficher en UTF-8 : Fonction utf8_decode() Sélectionnez echo utf8_decode( 'Ici mon texte en UTF-8' ); La différence entre les deux méthodes est flagrante. Faisons un petit test pour nous en convaincre. header( 'content-type: text/html; charset=utf-8' ); echo 'Texte accentué Dans test2.php nous mettons ce code : Ouvrons-les dans le navigateur. Mais pourquoi utf8_DEcode() alors que l'on veut ENcoder en UTF-8 ? Encodage Apache AddDefaultCharset utf-8
rewrite Available Languages: en | fr Summary This module uses a rule-based rewriting engine (based on a regular-expression parser) to rewrite requested URLs on the fly. It supports an unlimited number of rules and an unlimited number of attached rule conditions for each rule, to provide a really flexible and powerful URL manipulation mechanism. The URL manipulations can depend on various tests, of server variables, environment variables, HTTP headers, or time stamps. This module operates on the full URLs (including the path-info part) both in per-server context (httpd.conf) and per-directory context (.htaccess) and can generate query-string parts on result. Further details, discussion, and examples, are provided in the detailed mod_rewrite documentation. Quoting Special Characters Environment Variables This module keeps track of two additional (non-standard) CGI/SSI environment variables named SCRIPT_URL and SCRIPT_URI. Example Rewriting in Virtual Hosts RewriteEngine On RewriteOptions Inherit
URL Rewriting | redirecting URLs with Apache’s mod_rewrite Path // → → URL REWRITING The Apache server’s mod_rewrite module gives you the ability to transparently redirect one URL to another, without the user’s knowledge. This opens up all sorts of possibilities, from simply redirecting old URLs to new addresses, to cleaning up the ‘dirty’ URLs coming from a poor publishing system — giving you URLs that are friendlier to both readers and search engines. This page was last updated on 2012-08-21 An Introduction to Rewriting Readable URLs are nice. However, there are some cases when the best possible information design can’t stop your site’s URLs from being nigh-on impossible to use. This is a horrible URL, but it and its brethren are becoming increasingly prevalent in these days of dynamically-generated pages. It exposes the underlying technology of the website (in this case ASP). Luckily, using rewriting, we can clean up this URL to something far more manageable.
A T-SQL Regular Expression Library for SQL Server 2005. Free source code and programming help Introduction With the advent of CLR integration into SQL Server 2005, it has become incredibly easy to extend the power of the T-SQL programming language. Two of the areas that can be improved upon by way of CLR integration are string matching and string manipulation. Background T-SQL has a handful of basic string matching functions (e.g. SQL Server 2005 now allows you to create user defined functions (among other things) using your .NET language of choice. Using the Code General Approach My objective here is to wrap some of the more commonly used static methods of the RegEx class in the .NET Framework into something useable in a T-SQL environment. Interface All four of the functions listed in this article share the same first two parameters: @Input NVARCHAR(MAX) This is the string to be analyzed. @Pattern NVARCHAR(MAX) This is the regular expression which will be executed against the @Input parameter. In addition, all four functions share the same last parameter. @IgnoreCase BIT Functions Name
Crazy Advanced Mod_Rewrite Tutorial Are you an advanced mod_rewrite expert or guru? This article is for YOU too! Just make sure to read all the way to the bottom.. The following undocumented techniques and methods will allow you to utilize mod_rewrite at an "expert level" by showing you how to unlock its secrets. Most if not all web developers and server administrators struggle with Apache mod_rewrite. Why mod_rewrite is so tough ^ I have come to the conclusion, after many hours of zenful thought, that the reason mod_rewrite is so tough is pretty obvious, people are trying to apply regular-expressions to URLs and Variables that they don't really understand. Hit-Or-Miss with mod_rewrite ^ A lot of the mod_rewrite "experts" and "gurus" floating around the net absolutely know their mod_rewrite, but what separates them from a beginner or novice is for the most part an understanding of what the URLS and Variables look like that are targeted by the regular expressions. Pretty simple right? Why? When Not To Use Mod_Rewrite ^ <? YES!
Appréhender WordPress pour un développeur Appréhender WordPress, c’est comprendre ce que ce CMS propose. Beaucoup de développeurs « qui débutent sur WordPress » auront tendance – au départ – à se précipiter sur le fonctionnel et à utiliser ce qu’ils savent déjà. C’est sans aucun doute la première erreur qu’ils commettront alors qu’ils connaissent très bien l’adage du développeur « ne pas réinventer la roue ». Pour tout framework (Symfony, zend PHP, AngularJs…), le développeur se documentera préalablement et gardera pour référence la documentation officielle. Pour WordPress, la documentation officielle se résume en un mot sur la toile, à savoir : le Codex. Le codex de WordPress Le Codex – disponible en partie en français si nécessaire – est écrit et maintenu par les utilisateurs (environ 25 000 utilisateurs enregistrés). WordPress dispose d’une API à partir de laquelle il est possible de récupérer et d’enregistrer toute information susceptible de servir notre objectif. Les Handbooks de WordPress Développer un thème WordPress
Apache mod_rewrite mod_rewrite provides a way to modify incoming URL requests, dynamically, based on regular expression rules. This allows you to map arbitrary URLs onto your internal URL structure in any way you like. It supports an unlimited number of rules and an unlimited number of attached rule conditions for each rule to provide a really flexible and powerful URL manipulation mechanism. Rewrite rules can operate on the full URLs, including the path-info and query string portions, and may be used in per-server context (httpd.conf), per-virtualhost context (<VirtualHost> blocks), or per-directory context (.htaccess files and <Directory> blocks). Since mod_rewrite is so powerful, it can indeed be rather complex. mod_rewrite: A Beginner's Guide to URL Rewriting This article was written in 2002 and remains one of our most popular posts. If you’re keen to learn more about URLs, you may find this recent article on the “www” prefix, by Craig Buckler, of great interest. So you’re a web developer who has all the bells and whistles on your site, creates Web-based applications that are both beautiful and work well. But what about these issues? Applications Must Be Safe A user must not be able to harm your site in any way by modifying a URL that points to your applications. For example, imagine we have a simple script that shows all the products in a category. Generally, it’s called like this: myapp.php? But what will this application do if ScriptKiddie(tm) comes and types this in his browser: myapp.php? Well, many of the sites I’ve seen will drop some error message complaining about use of the wrong SQL query, invalid MySQL resource ID, and so on. Applications Must Be Search-Engine Friendly myapp.php? myapp.php “you have an error in your sql syntax” .php -forum
Rejex lets you craft regular expressions on-the-fly Rejex is a very handy little site for building and testing regular expressions on the fly. It's composed of four simple text boxes and a very informative cheat sheet (not shown above, but after the jump). You feed your text into the "Test String" box (the middle one), and then your expression into the top box, and immediately see the matches in the bottom box. Here I am searching for instances of the letter "o" which are either at the beginning or the end of a word, so I got a match for "over" but not for "fox". Half the tool's value lies with the informative cheat sheet, showing you exactly what each regex character does. The regex cheat sheet: