When I started to work with WordPress I didn’t know anything about how databases works or anything related to encoding and character set, but as I started into adventure myself on places like
pre_get_posts, and the
WP_Query filters such as
posts_where, I quickly found that understanding how the database works was a key to unlocking better performance.
Once I was trying to do a search on some User meta data and I didn’t know why one of my results where not been shown as I expected so delving further and debugging I found that there an information called Collation which is the set of Rules that your database table will follow.
The problem was this meta data was a
city value, and I did not have control over the user input so it needed to be case-insensitive, which was not happening because the Collation was set to be
utf8_bin that will make your MySQL compare queries that involve
LIKE via a Binary structure so it will
A is not equal to
This case sensibility issue on WordPress databases or any MySQL is easy to solve, you just need to change the collation of the tables that you want to be insensitive by executing the following SQL query on your database.
ALTER TABLE `wp_posts` CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci; ALTER TABLE `wp_postmeta` CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;
_ci at the end will convert the Collation to be Case Insensitive, remember that changing the Collation of a table might lead you to have security problems of people trying to pose as Administrator account, which in WordPress is not the case because there are validations for that but if you are in another system you might want to double check.
No próximo sábado vou estar em São Paulo falando sobre como contribuir para o WordPress sendo você um desenvolvedor, designer, tradutor ou usuário!
Sendo a grande força da ferramenta a sua comunidade extremamente colaborativa e receptiva a novos membros, vamos nesses 40 minutos entender como funciona a participação e contribuição individual para que essa grande qualidade do WordPress seja feita de forma sólida e bem estruturada pela comunidade Brasileira.
Confira o resto da programação do WordCamp São Paulo 2014 e faça parte desse evento.
Espero você por lá!
Last week I decided to install Mac OS X Yosemite (
v10.10), and as expected a lot of things changed under the hood on Mac OS, so things are still not as easy to install as they were on my Mavericks installation.
Almost all of the problems I faced so far I was able to find articles on how to solve them, but when I was trying to install
fswatch I had a problem with the GCC compiler.
After digging a bit on Homebrew’s GitHub Issues I found that you can edit the GCC formula and apply a patch that will make it work on Yosemite.
When Homebrew was installing the Bootstrap (
make bootstrap) the following error was presented on my terminal:
config.status: executing default commands make: *** [stage2-bubble] Error 2 make: *** [bootstrap] Error 2 READ THIS: https://github.com/Homebrew/homebrew/wiki/troubleshooting These open issues may also help: gcc: compatibility 10.10 (https://github.com/Homebrew/homebrew/pull/31466) gcc 4.8.3 bottle has invalid omp.h header (https://github.com/Homebrew/homebrew/issues/29670) MacOS.(gcc|clang|llvm)_version can return nil (https://github.com/Homebrew/homebrew/issues/18781)
It’s easy do resolve the issue, you only need:
brew edit gcc
Then you will find the following:
require "formula" class Gcc < Formula def arch if Hardware::CPU.type == :intel if MacOS.prefer_64_bit? "x86_64" else "i686" end elsif Hardware::CPU.type == :ppc if MacOS.prefer_64_bit? "powerpc64" else "powerpc" end end end def osmajor `uname -r`.chomp end
Then add the code below the
osmajor method definition:
# edit by b.nelissen 20140805 # tobinjones patch gcc https://github.com/Homebrew/homebrew/issues/29845 patch do url "https://gcc.gnu.org/bugzilla/attachment.cgi?id=33180" sha1 "def0cb036a255175db86f106e2bb9dd66d19b702" end
Now you will need to run
brew install gcc again and you should be good to go.
I’ve been working for almost 2 months now with the guys from MailPoet, and there I’ve done some support along with @rafaehlers and from what I can see from his report on most of the tickets we receive are caused by bad email servers on shared hosting.
Don’t get me wrong, I’m not saying that they don’t know how to do it, but the way they need to do thing to avoid spammers make they email server a crap one.
Começou nesta segunda feira a #cpbr7, e hoje de madrugada eu estou largando o calor do capiroto que faz no Rio de Janeiro para ir para a terra da Garoa, curtir um evento Nerd com a galera da Comunidade do WordPress Brasil.
Como nenhum de nós está de bobeira brincando, vamos lá não só curtir um evento e falar umas besteiras mas também iremos fazer algumas palestras informativas sobre o WordPress.