Kalian уже ответил, что таких файлов может быть несколько - все зависит от используемого шаблона
вопрос изначально поставлен некорректно - вам нужен не файл а функция, которая выводит текст - для вордпресса это the_excerpt(), иногда the_content() - тут тоже зависит от шаблона...
откройте файл functions.php вашего шаблона и добавьте такие строки:
add_filter('excerpt_length','new_excerpt_length');
function new_excerpt_length() {
return 20;
}
20 - это кол-во слов, вместо 20 можете поставить нужное значение
был когда-то такой журнал - "Техника Молодежи", а в нем была обалденная рубрика которая так и называлась "зачем просто если можно сложно"
в ней описывались всякие изобретения вроде восьмиколесного велосипеда с гироскопом на основе ртути - т.е. вещи которые вроде бы работают, но keep it simple ☝
ваши три слоя фона идеально бы подошли к той рубрике... а в те времена, когда наши корабли бороздят просторы вселенной подобные вещи решаются достаточно просто с помощью трех букв и одной цифры :)
имеется ввиду CSS 3 - с помощью нехитрых манипуляций можно добиться корректного отображения даже в 7 и 8 ослах
я не говорил "невозможно", я говорил "нецелесообразно"
специально проверил ссылку - харьковский, польский и американский айпишники показали идентичные результаты в блоке "С этой статьей также смотрят", т.е. там реализация не на основе айпишника
если вернуться к примеру про Василия Пупкина - то как быть если таких Василиев 100? а если 1000? Для каждого ай пи хранить свой результат статей, которые читают?
по поводу СЕО - не спорю, тут скорее не физика а лирика, хотя мой опыт (несколько сотен сайтов на ВП) говорит о том что "похожие статьи", выводимые вместе с аносами и оформленые в стиле основного материала отлично работают, т.е. основной материал добавляется нужными ключами+качественная перелинковка
а вот по поводу юзабилити я возможно не так обьяснил...
смотрите, допустим имеется интернет-магазин, в котором пользователь просматривает телефон Nokia X8... Если мы сделаем "С этой статьей также смотрят" на основе тегов (вполне логично что теги будут вроде Nokia, Simbian, сенсорный и т.д.) - то пользователю будут выведены действительно похожие телефоны...
но если мы доверим это дело пользователю, и будем выводить лишь то что он посмотрел... представьте что сразу после телефона Вася П. посмотрел на стиральную машину, или утюг, или пылесос - соответственно следующий посетитель увидит что вместе с Nokia X8 смотрят про стиральные машины/утюги/пылесосы
с новостными или информационными сайтами аналогично - если статья про футбол то логично показывать как минимум спортивные статьи...
siv1987: Чего нету? Ты бы сначала определился с понятием "С этой статьей также смотрят". В этой теме уже дали два возможных варианта - related похожие; случайные записи. Если у тебя оно означает (переходы_с_статьи + кол_статей)/общее_число_мемберов * текущая_дата то это только под заказ.
случайные менее интересно, а вот по поводу релейтед дополню - для вордпресса есть два наиболее распространенных варианта релейтовости (во классное слово придумал )))
первое - делаем "похожесть" на основе категорий, ведь вполне логично что статьи из одной категории будут чем-то похожи...
второе - "похожесть" на основе тегов, причина аналогична
по поводу плагинов - есть дофига и еще немножко, но меня всегда поражала загадочная блоггерская душа, пытающаяся все делать через ж*, простите через плагины - где-то даже плагин для дат видел )))
вот решение на скорую руку, на базе тегов
<?php
//for use in the loop, list 5 post titles related to first tag on current post
$tags = wp_get_post_tags($post->ID);
if ($tags) {
$first_tag = $tags[0]->term_id;
$args=array(
'tag__in' => array($first_tag),
'post__not_in' => array($post->ID),
'showposts'=>4,// кол-во постов, которые "смотрели" вместе с этой статьей
'caller_get_posts'=>1
);
$my_query = new WP_Query($args);
if( $my_query->have_posts() ) {
while ($my_query->have_posts()) : $my_query->the_post(); ?>
<a href="<?php the_permalink() ?>" rel="bookmark" title="Permanent Link to <?php the_title_attribute(); ?>"><strong><?php the_title(); ?></strong></a><br />
<?php
endwhile;
}
wp_reset_query();
}
?>
десяток строк позволит обойтись без плагина, по категориям можно сделать аналогично... а вообще код предлагаю рассматривать как заготовку - например дополнительно можно показывать превьюшки или первые 20 слов
Айпишник, просмотревщий страницу с этой записью просматривал также следующие записи на этом сайте.
Выводим список этих самых «следующих записей» за весь период жизни сайта (записи).
в принципе в программировании не бывает ничего невозможного - зато существует нецелесообразное...
обьясню что имелось ввиду
1. нецелесообразно с точки зрения нагрузки
представьте что зашел на сайт Василий Пупкин и с интересом посмотрел материал, в котором девченка огрела табачника венком по роже... Айпишник Василия нужно уточнить, верно? а кроме того данный айпишник нужно где-то держать, тоже верно? Ну и соответственно где-то нужно держать данные о том что именно просматривал Василий, ведь другой айпи может просматривать что-то другое... а если он больше ничего не просмотрит?
Василий уходит, на сайт приходит Маня Пупкина - а перед тем как выдать ей материал, сервер должен будет лишний раз убедиться, что айпи Мани и Васи совпадают, лишний раз дернуть базу - что же там смотрел Василий... а после просмотра еще и сделать изменения в базе - ведь нужно же сохранить данные о том что просматривала Маня...
2. нецелесообразно с точки зрения СЕО
Напоминаю, что наш Василий смотрит статью про букет и про рожу - именно эти слова являются нашими ключами... если выводим related статьи из этой же категории или с этими же тегами, то общее кол-во ключей при грамотном подходе увеличится (а если релейтед пойдут с анонсами, т.е. ключи будут окутаны тематическим текстом как теплым одеялом - то вообще сказка)
Теперь представьте, что Вася П. которому до лампочки все слова из трех букв включая СЕО смотрит сразу же после данной статьи что-то про сиськи, или про футбол, или про марсиан...
другими словами - Маня Пупкина, которая откроет ту же самую статью видит, что вместе с этой статьей смотрят про сиськи и марсиан...
2.1 по той же самой причине нецелесообразно с точки зрения юзабилити/удержания посетителя на сайте
много букв получилось, но надеюсь что убедил не поступать нецелесообразно...
ТС, вы случайно в битве экстрасенсов не учавствовали?
"помогите не работает" - а где не работает кому нужно угадывать? какой движок?
в связи с новым украинским налоговым законодательством мой штатный экстрасенс уволился, но все же попробую дать универсальное решение, не зависящее от движка - надеюсь поможет:
if ($_SERVER['REQUEST_URI'] == '/'){
//выводим то что на главной
}else{
//выводим то что на внутренних
}
assas, как было сказано выше - вы банально путаете верстку и натяжку макета на двиг
есть вполне грамотные верстальщики, которые не возьмутся за ваш проект лишь из-за фразы
Большинство модулей встанут автоматически, но в некоторых из них нужно править исходный код, чтобы привести их в соответствие с дизайном.
другими словами верстальщик не обязан знать PHP
а если из личного опыта - иногда джумловские модули бывают настолько кривыми, что скормить их валидатору удается не менее чем за день
ТЗ составлено в целом четко, с одной поправочкой:
вы верно заметили о разделении труда, и соответственно вам нужна не верстка, а изготовление/натяжка шаблона/макета - попробуйте поискать исполнителя по этому критерию, но учтите что бюджет будет выше...
зы
если к вечеру пятницы никого не найдете - скиньте в личку, посмотрю чем вы там вебланс напугали
Kalian уже ответил, что таких файлов может быть несколько - все зависит от используемого шаблона
вопрос изначально поставлен некорректно - вам нужен не файл а функция, которая выводит текст - для вордпресса это the_excerpt(), иногда the_content() - тут тоже зависит от шаблона...
откройте файл functions.php вашего шаблона и добавьте такие строки:
add_filter('excerpt_length','new_excerpt_length');function new_excerpt_length() {
return 20;
}
20 - это кол-во слов, вместо 20 можете поставить нужное значение
gradient
box-shadow
border-radius
нужно три слоя фона:
был когда-то такой журнал - "Техника Молодежи", а в нем была обалденная рубрика которая так и называлась "зачем просто если можно сложно"
в ней описывались всякие изобретения вроде восьмиколесного велосипеда с гироскопом на основе ртути - т.е. вещи которые вроде бы работают, но keep it simple ☝
ваши три слоя фона идеально бы подошли к той рубрике... а в те времена, когда наши корабли бороздят просторы вселенной подобные вещи решаются достаточно просто с помощью трех букв и одной цифры :)
имеется ввиду CSS 3 - с помощью нехитрых манипуляций можно добиться корректного отображения даже в 7 и 8 ослах
А как он может быть разный, если блок показывает, что другие посетители читали вместе с этой статьей?
ведь это ваша цитата, верно?
насколько я понял из данной фразы - вы хотите отталкиваться именно от айпи
Очень даже возможно.
Однако, наверняка есть способы нагрузку эту оптимизировать.
http://www.kakprosto.ru/kak-63906-kak-rasschitat-bolnichnyy-iz-mrot
я не говорил "невозможно", я говорил "нецелесообразно"
специально проверил ссылку - харьковский, польский и американский айпишники показали идентичные результаты в блоке "С этой статьей также смотрят", т.е. там реализация не на основе айпишника
если вернуться к примеру про Василия Пупкина - то как быть если таких Василиев 100? а если 1000? Для каждого ай пи хранить свой результат статей, которые читают?
по поводу СЕО - не спорю, тут скорее не физика а лирика, хотя мой опыт (несколько сотен сайтов на ВП) говорит о том что "похожие статьи", выводимые вместе с аносами и оформленые в стиле основного материала отлично работают, т.е. основной материал добавляется нужными ключами+качественная перелинковка
а вот по поводу юзабилити я возможно не так обьяснил...
смотрите, допустим имеется интернет-магазин, в котором пользователь просматривает телефон Nokia X8... Если мы сделаем "С этой статьей также смотрят" на основе тегов (вполне логично что теги будут вроде Nokia, Simbian, сенсорный и т.д.) - то пользователю будут выведены действительно похожие телефоны...
но если мы доверим это дело пользователю, и будем выводить лишь то что он посмотрел... представьте что сразу после телефона Вася П. посмотрел на стиральную машину, или утюг, или пылесос - соответственно следующий посетитель увидит что вместе с Nokia X8 смотрят про стиральные машины/утюги/пылесосы
с новостными или информационными сайтами аналогично - если статья про футбол то логично показывать как минимум спортивные статьи...
возможно вы что-то делаете не так?
кодировка не мешает работе двига, а в тех случаях когда нужно взять данные именно в ютф, отлично выручает
блаблабла = iconv("UTF-8", "CP1251//IGNORE", блаблабла);нг неплохой выбор, и кроме всего прочего умеет очень гибко работать с урлами
если в дле всего 3 варианта для ЧПУ, то нг можно настроить как угодно и при желании "закосить" урлами под 90% существующих движков...
имхо достаточно важный ньюанс, особенно когда нужно портировать уже проиндексированные страницы
Чего нету? Ты бы сначала определился с понятием "С этой статьей также смотрят". В этой теме уже дали два возможных варианта - related похожие; случайные записи. Если у тебя оно означает (переходы_с_статьи + кол_статей)/общее_число_мемберов * текущая_дата то это только под заказ.
случайные менее интересно, а вот по поводу релейтед дополню - для вордпресса есть два наиболее распространенных варианта релейтовости (во классное слово придумал )))
первое - делаем "похожесть" на основе категорий, ведь вполне логично что статьи из одной категории будут чем-то похожи...
второе - "похожесть" на основе тегов, причина аналогична
по поводу плагинов - есть дофига и еще немножко, но меня всегда поражала загадочная блоггерская душа, пытающаяся все делать через ж*, простите через плагины - где-то даже плагин для дат видел )))
вот решение на скорую руку, на базе тегов
десяток строк позволит обойтись без плагина, по категориям можно сделать аналогично... а вообще код предлагаю рассматривать как заготовку - например дополнительно можно показывать превьюшки или первые 20 слов
Выводим список этих самых «следующих записей» за весь период жизни сайта (записи).
в принципе в программировании не бывает ничего невозможного - зато существует нецелесообразное...
обьясню что имелось ввиду
1. нецелесообразно с точки зрения нагрузки
представьте что зашел на сайт Василий Пупкин и с интересом посмотрел материал, в котором девченка огрела табачника венком по роже... Айпишник Василия нужно уточнить, верно? а кроме того данный айпишник нужно где-то держать, тоже верно? Ну и соответственно где-то нужно держать данные о том что именно просматривал Василий, ведь другой айпи может просматривать что-то другое... а если он больше ничего не просмотрит?
Василий уходит, на сайт приходит Маня Пупкина - а перед тем как выдать ей материал, сервер должен будет лишний раз убедиться, что айпи Мани и Васи совпадают, лишний раз дернуть базу - что же там смотрел Василий... а после просмотра еще и сделать изменения в базе - ведь нужно же сохранить данные о том что просматривала Маня...
2. нецелесообразно с точки зрения СЕО
Напоминаю, что наш Василий смотрит статью про букет и про рожу - именно эти слова являются нашими ключами... если выводим related статьи из этой же категории или с этими же тегами, то общее кол-во ключей при грамотном подходе увеличится (а если релейтед пойдут с анонсами, т.е. ключи будут окутаны тематическим текстом как теплым одеялом - то вообще сказка)
Теперь представьте, что Вася П. которому до лампочки все слова из трех букв включая СЕО смотрит сразу же после данной статьи что-то про сиськи, или про футбол, или про марсиан...
другими словами - Маня Пупкина, которая откроет ту же самую статью видит, что вместе с этой статьей смотрят про сиськи и марсиан...
2.1 по той же самой причине нецелесообразно с точки зрения юзабилити/удержания посетителя на сайте
много букв получилось, но надеюсь что убедил не поступать нецелесообразно...
ТС, вы случайно в битве экстрасенсов не учавствовали?
"помогите не работает" - а где не работает кому нужно угадывать? какой движок?
в связи с новым украинским налоговым законодательством мой штатный экстрасенс уволился, но все же попробую дать универсальное решение, не зависящее от движка - надеюсь поможет:
if ($_SERVER['REQUEST_URI'] == '/'){//выводим то что на главной
}else{
//выводим то что на внутренних
}
assas, как было сказано выше - вы банально путаете верстку и натяжку макета на двиг
есть вполне грамотные верстальщики, которые не возьмутся за ваш проект лишь из-за фразы
другими словами верстальщик не обязан знать PHP
а если из личного опыта - иногда джумловские модули бывают настолько кривыми, что скормить их валидатору удается не менее чем за день
ТЗ составлено в целом четко, с одной поправочкой:
вы верно заметили о разделении труда, и соответственно вам нужна не верстка, а изготовление/натяжка шаблона/макета - попробуйте поискать исполнителя по этому критерию, но учтите что бюджет будет выше...
зы
если к вечеру пятницы никого не найдете - скиньте в личку, посмотрю чем вы там вебланс напугали
ТС, обязательно напишите
даже если вашим движком никто и никогда не воспользуется, вы получите то что не измеряется в денежном эквиваленте - опыт