вторник, 19 февраля 2013 г.

Magento robots.txt




Magento robots.txt
Magento robots.txt
Magento comes without robots.txt functionality. It can be useful to add one yourself to tell the search engines where they are not allowed to index. It will hide your javascript files, hide SID parameters and prevent some duplicate content. It will help your SEO process and reduces resources on your server. In this blogpost I explain you how to set your own Magento robots.txt using an existing example and using an extension. Both solutions are easy to handle.

Import/Export Large MYSQL Databases

When working with MYSQL I often use phpMyAdmin, which is a nice GUI way to manipulate my database. But some operations won't work in phpMyAdmin when the database is too large. In particular, you can't import or export really large databases using phpMyAdmin. So sometimes you need to do things on the command line.

So I thought I'd document some of the command line snippets we use frequently. In the following, replace [USERNAME] with your mysql username, [DBNAME] with your database name, [/path_to_file/DBNAME] with the path and name of the file used for the database dump, and [/path_to_mysql/] with the path to mysql bin (like /Applications/MAMP/Library/bin/).

Copy/Export a Large Database

MYSQL has no 'Copy' function. You create a copy by dumping the database with mysqldump.
To dump the database and gzip it at the same time, use the following. This will prompt you for your password.

mysqldump -u [USERNAME] -p [DBNAME] | gzip > [/path_to_file/DBNAME].sql.gz

Import a Large Database

If you want to replace the database with a fresh dump created by the above process, do the following.
First, unzip the file.

gzip -d [/path_to_file/DBNAME].sql.gz
Get to a mysql prompt (you will be asked for your password.)

[/path_to_mysql/]mysql -u [USERNAME] -p
Then do the following to wipe out the old database and replace it with the new dump:

SHOW DATABASES;
DROP DATABASE [DBNAME];
CREATE DATABASE [DBNAME];
USE [DBNAME];
SOURCE [/path_to_file/DBNAME].sql;

Conditional Dumps

Sometimes the search index is huge and you want to omit it from the dump. Do so with:

mysqldump -u [USERNAME] -p [DBNAME] --ignore-table=[DBNAME].search_index | gzip > [/path_to_file/DBNAME].sql.gz
There are actually a number of tables you could exclude, like the sessions table, the watchdog table and all the cache* tables.
But if you use the above technique to destroy and recreate the database after doing this, you will be missing all those excluded tables. So you will want to do a two step process instead:
First, create a backup with ONLY the table information, no data.

mysqldump -u [USERNAME] -p [DBNAME] --no-data | gzip > [/path_to_file/DBNAME].info.sql.gz
Then create a backup, including only data from the tables you need.

[path_to_mysql/]mysqldump -u [USERNAME] -p [DBNAME]  --no-create-info --ignore-table=[DBNAME].search_index --ignore-table=[DBNAME].cache --ignore-table=[DBNAME].cache_block --ignore-table=[DBNAME].cache_content --ignore-table=[DBNAME].cache_filter --ignore-table=[DBNAME].cache_form --ignore-table=[DBNAME].cache_menu --ignore-table=[DBNAME].cache_mollom --ignore-table=[DBNAME].cache_page --ignore-table=[DBNAME].cache_pathdst --ignore-table=[DBNAME].cache_pathsrc --ignore-table=[DBNAME].cache_views | gzip > [/path_to_file/DBNAME].data.sql.gz;
Well that's a lot of typing. Wouldn't it be nice if there was a wildcard we could use instead of typing out all those cache_ tables? Well there is!! You can do:

[path_to_mysql/]mysqldump -u [USERNAME] -p [DBNAME]  --no-create-info --ignore-table=[DBNAME].search_index --ignore-table=[DBNAME].cache% | gzip > [/path_to_file/DBNAME].data.sql.gz;
After doing this, just import the two files as above, first the one with only the table info, and then the data. Result, a (relatively) small database with all the optional tables emptied out.
Note that the wildcard trick above is not documented anywhere that I can see, so you'll want to test that it works in your setup.

Источник 

вторник, 8 января 2013 г.

Magento аттрибуты

Отображение атрибутов на странице списка товаров

Было:
Изображение

Стало:
Изображение



четверг, 27 декабря 2012 г.

Zend Router

resources.router.routes.news.type = "Zend_Controller_Router_Route_Regex"
resources.router.routes.news.route = "news/(.*)\.html"
resources.router.routes.news.defaults.controller= "news"
resources.router.routes.news.defaults.action= "index"
resources.router.routes.news.defaults.name = "none"
resources.router.routes.news.map.1 = "name"
resources.router.routes.news.reverse = "news/%s.html"

разберем построчно
с 1ой строкой все понятно;
во 2ой задается регулярное выражение;
3,4,5 настройка контроллера, экшена и значения переменной name по умолчанию;
6 (предпоследняя) маппинг параметров у нас здесь один параметр и он будет присвоен переменной name;
7ая строка при генерации ссылок через вью хэлпер url будет использоватся это выражение.
 







resources.router.routes.id.type = "Zend_Controller_Router_Route_Regex"
resources.router.routes.id.route = "articles/(\w+)"
resources.router.routes.id.defaults.module = default
resources.router.routes.id.defaults.controller = articles
resources.router.routes.id.defaults.action = id
resources.router.routes.id.map.1 = "id"
resources.router.routes.id.reverse = "articles/%s"
Вы укажете Zend Framework при переходе на страницу типа articles/5 определить 5 как id.
Получить значение Вы можете розместив в action:


$this->getRequest()->getParam('id');
Zend router можно реализовать и в другом формате:








resources.router.routes.articles.type = "Zend_Controller_Router_Route_Regex"
resources.router.routes.articles.route = "articles/tag/(\w+)"
resources.router.routes.articles.defaults.module = default
resources.router.routes.articles.defaults.controller = articles
resources.router.routes.articles.defaults.action = tag
resources.router.routes.articles.map.1 = "tag"
resources.router.routes.articles.reverse = "articles/tag/%s"
Тут, соотвественно, данные будут в articles/tag/zend.
 

пятница, 23 ноября 2012 г.

пятница, 16 ноября 2012 г.

Перенос сайта WordPress на новый домен

14 октября 2007 г. Главная WordPress
Иногда может возникнуть ситуация, когда необходимо сайт, работающий на движке WordPress, перенести на новый домен. Т.е. суть данного действа заключается только в изменении имени домена, все содержимое же, равно как и структура ссылок, остается прежним. При этом не маловажный момент - сохранение показателей тИЦ и PR.
К данному вопросу необходимо подходить с полным пониманием дела, ибо обратное может быть чревато неприятными последствиями.

среда, 18 июля 2012 г.

Особенности работы jQuery.live()

На работе столкнулись с “особенностью” работы jQuery.live(), на которую хотелось бы обратить внимание, потому как, судя по всему, отнюдь не все о ней знают (и в результате чего пишут неработающий код).
Итак, простой пример - навешивание двух событий на один и тот же элемент:

<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
  <meta http-equiv="Content-type" content="text/html; charset=UTF-8" />
  <title>jQuery.live() test pagetitle>
  <script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js">script>
  <script type="text/javascript">
  jQuery(function() {
    $("a").bind("click", function(e) {
      alert("a");
      return false;
    });
    $("a").bind("click", function(e) {
      alert("b");
      return false;
    });
  });
  script>
head>
<body>
  <a href="http://blog.fxposter.org/">Блог FX-аa>
body>
html>
Пример можно посмотреть здесь. В результате клика на ссылку - получаем 2 alert-а, всё хорошо, ожидаемо и предсказуемо.
Переписываем код для работы с jQuery.live(). Для тех, кто в танке - live() вешает событие не на сам элемент, а на document. В результате bubbling-а событие, которое произошло над каким-либо элементом поднимается вверх по DOM-дереву и соответственно вызывает обработчики всех элементов, которые оно встретит. Если вы и этого не знали - то вам не нужно читать мой блог, а пора идти и покупать книгу по JavaScript-у (мне, кстати, тоже давно пора, но всё никак не соберусь). Итак, в конце концов событие доходит до document-а и обработчики вызываются у него. Обработчик, который устанавливает jQuery.live() проверяет - соответствует ли event.target (а именно здесь хранится обьект DOM-дерева, с которым произошло событие) соответствующему селектору (в данном случае - это селектор “a”) и если соответствует - то выполняет обработчик.
Преимущества и недостатки - это тема отдельной статьи. Если не уклонятся в сторону оптимизации, то основным преимуществом, на мой взгляд, является тот факт, что обработчики, навешенные live()-ом будут запускаться даже для элементов, которые были динамически добавлены на страницу, в отличии от bind()-обработчиков, которые на эти элементы нужно будет навешивать вручную (если непонятно, почему это работает именно так - читаем предыдущий абзац, если все равно непонятно - идем покупать всё ту же книгу).
Далее - зачем нужен “return false” в конце обработчика? Он предотвращает от того, чтобы вызывалось действие по умолчанию (в данном случае - переход по ссылке и событие не поднималось выше). Чаще всего JS-разработчики вообще не думают о bubbling-е и под “return false” понимают только “отмену действия по умолчанию”, ну или они вообще не знают, что именно происходит и пишут “return false”, потому что так работает.
Такое отношение jQuery частенько прощает. Но не в случае с live()-методом. Попробуем запустить следующий пример:

<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
  <meta http-equiv="Content-type" content="text/html; charset=UTF-8" />
  <title>jQuery.live() test pagetitle>
  <script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js">script>
  <script type="text/javascript">
  jQuery(function() {
    $("a").live("click", function(e) {
      alert("a");
      return false;
    });
    $("a").live("click", function(e) {
      alert("b");
      return false;
    });
  });
  script>
head>
<body>
  <a href="http://blog.fxposter.org/">Блог FX-аa>
body>
html>
В результате клика теперь выскакивает только один alert. Пора обратится к документации:
# To stop further handlers from executing after one bound using .live(), the handler must return false. Calling .stopPropagation() will not accomplish this.
Хаха. В данном случае jQuery интерпретирует false “несколько иначе”. :)
Для того, чтобы “пофиксить” подобный баг нужно обратится все к тому же bubbling-у и обработке событий и сделать именно то, что предполагается разработчиком - “отменить действие по умолчанию”. Это делается с помощью метода event.preventDefault() (пример):

<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
  <meta http-equiv="Content-type" content="text/html; charset=UTF-8" />
  <title>jQuery.live() test pagetitle>
  <script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js">script>
  <script type="text/javascript">
  jQuery(function() {
    $("a").live("click", function(e) {
      alert("a");
      e.preventDefault();
    });
    $("a").live("click", function(e) {
      alert("b");
      e.preventDefault();
    });
  });
  script>
head>
<body>
  <a href="http://blog.fxposter.org/">Блог FX-аa>
body>
html>
И самое главное (барабанная дробь!) - при использовании bind() для навешивания обработчиков preventDefault() тоже можно использовать!
Наткнулись мы на эту “фичу”, когда у нас почему-то перестали вызываться некоторые обработчики
Напоследок, замечу еще одно - элемент, на который навешено хотя бы один обработчик события через bind() с “правильно работающим return false”, никогда не будет вызывать никакие live()-события. ;)

Источник