0
<< предыдущая заметкаследующая заметка >>
17 июля 2011
глюки после переезда

В связи с убийством сайта lleo.aha.ru у вас у всех не будет работать /install.php Это связано с тем, что, несмотря на то, что на lleo.aha.ru для запроса install.php (при вашем обращении к серверу-матке) переадресация по моей просьбе установлена самая что ни на есть прямая, но движок не был рассчитан на это и даже не умел обрабатывать ответ сервера «301 permanent remove». В будущем новый модуль install позволит вообще выбирать сервер инсталляции произвольно, но он пока не готов.

Я исправил install.php — теперь ответ 301 он обрабатывает и послушно идет, куда надо, если сервер переехал. Заодно удалось избавиться от модуля curl — это ужасное чудовище меня порядком подзаебало, и я рад что удалось сделать процедуру, которая делает без него всякие POST-запросы, в т.ч. с передачей файлов. Зато теперь даже на тех хостингах, где движок не мог установиться из-за отсутствия php-модуля curl (ужас, но и такое бывает), он тоже будет работать.

Как быть вам теперь? Варианта два:

1. Заменить свой /install.php, скачав новый: install.php

2. Залезть в /install.php чем-нибудь, хоть «фотоальбомом» в браузере (помните, есть такая штука в админке, по двойному щелчку мышкой она открывает выбранный файл на чтение, а далее по кнопке 'E' или кликнув на иконку в заголовке окна, файл можно редактировать). И исправить везде (я уж не помню, сколько раз встречается) 'lleo.aha.ru' на 'lleo.me'.

<< предыдущая заметка следующая заметка >>
пожаловаться на эту публикацию администрации портала
архив понравившихся мне ссылок
Оставить комментарий
Windows Opera
0
0
wott
Этот человек не загрузил свой юзерпик, и я подобрал ему этот. Человек, пишущий такое, должен именно так выглядеть, верно?
Прикольная правка :) curl-у надо только один параметр поправить что бы он перенаправления отрабатывал. Имхо он по умолчанию включен.

Интересно а этот новый модуль также работает паралельно с
десятком запросов и отрабатывает ssl ?
Linux Firefox
 Москва
0
0
lleo
Этот человек не загрузил свой юзерпик, и я подобрал ему этот. Человек, пишущий такое, должен именно так выглядеть, верно?
Отправка данных скриптом php по протоколу POST - исключительно прерогатива админа, просто по определению.

Используется в двух модулях - в инсталляторе и коммуникационном скрипте FIDO. Необходимость делать параллельно внешние запросы (админу, ага) или по ssl - здесь никогда еще не возникала.

ssl я использовал один раз в личном модуле sms, который получал с железки sms-модуля информацию о новой mms за номером таким-то, а затем бежал с ее номером в личный кабинет на сайте beeline.ru и тырил оттуда данные mms. Вот этот забавный изврат был сделан через curl.

Но зачем геморрой curl с его чудовищным интерфейсом настроек там, где можно написать свою простую и надежную процедуру?

У меня простой и понятный интерфейс:

$s=POST_file($files,$url,$post);

$url - адрес запроса, напр. http://lleo.aha.ru/blog/install
$files - путь к файлу для передачи одного файла, либо массив путей, если файлов несколько, либо '', если файлов передавать не надо
$post - массив переменных POST, напр: array('action'=>'do','key'=>'1','user'=>123), если переменных не передается - то не указывается


К тому же, помнится, я встречал хостинги (или кто-то из пользователей мне жаловался?), где curl не установлен. Это нормально, если из-за какого-то сраного curl, который нужен лишь для инсталляции, не встанет весь движок, которому curl для работы и не нужен?
Linux Ubuntu Firefox
0
0
Andrey Pozdnyakov
Все обновилось, кроме штук связанных с timelast:
Например:

uni: элементов 5

`timelast` timestamp NOT NULL default 'CURRENT_TIMESTAMP' on update CURRENT_TIMESTAMP
`timelast` timestamp NOT NULL default 'CURRENT_TIMESTAMP'

uni_timelast: необходимо изменить: `uni_timelast` timestamp NOT NULL default 'CURRENT_TIMESTAMP
Linux Ubuntu Firefox
0
0
Andrey Pozdnyakov
При попытке чендж филд:

uni_timelast: в `uni` изменено поле `timelast`

mysql_query("ALTER TABLE `uni` CHANGE `timelast` `timelast` timestamp NOT NULL default 'CURRENT_TIMESTAMP'")
Invalid default value for 'timelast
Linux Firefox
 Москва
0
0
lleo
Этот человек не загрузил свой юзерпик, и я подобрал ему этот. Человек, пишущий такое, должен именно так выглядеть, верно?
Не обращайте внимания!

Формат базы правильный, это просто разные представления в разных версиях MySQL, они и вводят скрипт в заблуждение.
Linux Ubuntu Firefox
0
0
Andrey Pozdnyakov
ok

Проблема с правами актуальна - ни одна функция не работает: ни камент оставить, ни пост написать, ни статистика. (Думаю, что это права, раньше исправлялось их сменой, правда, уже не помню на какие файлы - какие права...)
Linux Firefox
 Москва
0
0
lleo
Этот человек не загрузил свой юзерпик, и я подобрал ему этот. Человек, пишущий такое, должен именно так выглядеть, верно?
Хм...

Попробуйте исправить права на:
/ajax/comment.php (комментарии)
/ajax/editor.php (посты)

Видимо, надо ставить 664. Также можно поэкспериментировать с 644 и 666.

Вообще же - имеет смысл сперва открыть напрямую браузером /ajax/comment.php и посмотреть, что он напишет. Я бы так сделал, но не знаю адрес вашего блога.

Если окажется, что дело именно в этом - я поправлю это в движке.

Точнее - сделаю в новом /install модуль "restore permission", который бы шлялся и всюду исправлял права файлов и папок на нужные (или какие укажет админ). Чем мы хуже macosx в конце концов? ;)
Linux Ubuntu Firefox
0
0
Andrey Pozdnyakov
Опытным путем установлено что проблема не в самих файлах, а в папках. На папки (на все, кроме, наверное, tmp?) нужно ставить 755. На php файлы - 644. Вроде, все заработало.
Linux Firefox
 Москва
0
0
lleo
Этот человек не загрузил свой юзерпик, и я подобрал ему этот. Человек, пишущий такое, должен именно так выглядеть, верно?
Странно - неужели апач не запускал /ajax/*.php из-за прав на папку ajax?

Вы окажете мне большую услугу, если проведете пару экспериментов:

1. Вернете права на папку /ajax как было (чтоб не работал редактор), откроете браузером напрямую /ajax/editor.php и напишете, выдает ли он какую-то ошибку, и если да, то какую.

2. Попробуете поставить права 775 и 664 и посмотреть, работает ли с ними. Если не работает - видимо, для каждого хостинга придется делать свои установки прав (будем делать автоопределялку в новом install). Ведь если движок у меня (к примеру) нарожает папок и файлов с правами 755 и 644, то их потом я не смогу их редактировать, заходя по ftp.
Windows IE
0
0
D.iK.iJ
У меня на хостинге, например, файл нельзя редактировать если у него права ниже 666.
А в папку не создать скриптом новый файл, если у нее права не 777.
И скрипт не может изменять другие скрипты и файлы с правами ниже 755...

Чаще всего так: http://www.wr-script.ru/info/upload-and-chmod.php
Linux Firefox
 Москва
0
0
lleo
Этот человек не загрузил свой юзерпик, и я подобрал ему этот. Человек, пишущий такое, должен именно так выглядеть, верно?
Проблема в том, что некоторые особо умные хостинги НЕ ПОЗВОЛЯЮТ запускать файлы, у которых права ВЫШЕ 644 :)

Поэтому надо наверно делать модуль в инсталляторе, который займется автодетектом.

всего комментариев: 11

<< предыдущая заметка следующая заметка >>