Хочу с вашей помощью написать собственный менеджер для работы со статьями.
Нужно продумать алгоритм сперва.
Итак, мой вариант:

Имеем авторизацию, 2 уровня доступа (админ, 1, я + все остальные регистрированные участники) + гости.
Имеем админку, в ней можно: писать/редактировать/удалять новости и подтверждать.
Про 4ое чуть позже.

Все гости имеют права Read-only. Регистрированные участники - read & write.
Но как они напишут, статья не появится, а попадет в 4ый раздел админки, где у каждой такой статьи есть невыбранный чекбокс. Если админ его выберет - статья добавится и уберется из 4 раздела.

Еще крайне важно иметь комментирование и оценивание статьи. Комментирование такое:
гости пишут под ником Гость, регистрированные только под своим, ник админа красный. Все. Если нет конструктивных предложения, а они должны быть, то нужно приступать к написанию. Надеюсь на вашу помощь

Цитата

Регистрированные участники - read & write

Только тут следует отслеживать, чтобы участники могли редактировать только свои статьи, а администратор - любые.
И еще, я бы зарезервировал возможность создания нескольких учетных записей администраторов на случай разростания проекта.
А в целом, идея логична...

Должно быть N кол-ва групп (масок доступа) и пользователей, которые к этим группам относятся.
Надо предусматривать возможность премодерации статей, помимо этого - категории статей надо предусмотреть.

Цитата(Bikutoru @ 6.7.2005, 19:45)

участники могли редактировать

Они вообще не будут их редактировать, иначе премодерация ни к чему. Представь, человек написал хорошую статью, я ее подтвердил, а он потом ее редактирует... И он может там написать что угодно... Не есть гут...

Цитата(Mal @ 6.7.2005, 20:51)

Должно быть N кол-ва групп (масок доступа) и пользователей, которые к этим группам относятся.

Собственно я так и говорил

Цитата(Mal @ 6.7.2005, 20:51)

Надо предусматривать возможность премодерации статей, помимо этого - категории статей надо предусмотреть.

Дельное дополнение, спасибо

Цитата(Bikutoru @ 6.7.2005, 19:45)

И еще, я бы зарезервировал возможность создания нескольких учетных записей администраторов на случай разростания проекта.

Угу, гут, спасибо.

Итак, завтра начну к первым скриптам =)

Aliance ты определись. Тебе нужен паблишер, т.е. аля статьи по датам или тебе нужно что-то вроде журнала, где надо разбивать на выпуски и потом утверждать администратором целый выпуск.

Мне нужны статьи для сайта. Уверен, в основном буду писать я, но так же, неплохо бы иметь возхможность и гостям писать... Просто написал статью "Как включать компьютер" 6 июля - она появилась в списке ссылок, кликаем - открывается страница с этой статьей. Все можно вручную делать, но не хочеться тратить много сил, лучше я в php поупражняюсь

Использовать будем файлы. Начнем с регистрации.
Задача: сделать страничку с регистрацией (register.php), при регистрации перенаправлять на главную (index.php). Если пользователь зарегистрирован - выводить привествие, вида "Привет"+имя, если нет - форму для авторизации и ссылку на страницу регистрации. Иду делать... Как появятся первые подводные камни - прибегу сюда

Это сообщение отредактировал(а) Aliance - 6.7.2005, 20:42

Цитата(Aliance @ 6.7.2005, 21:41)

Использовать будем файлы.

База

Aliance
имхо база
Добавлено @ 20:46
Aliance
да и начинать с регу глупо.

Цитата(Opik @ 6.7.2005, 21:46)

да и начинать с регу глупо.

Почему?

Цитата(Mal @ 6.7.2005, 21:46)

База

Я так и хотел, но у меня 1 всего база осталась. Где я буду хранить остальную инфу о статьях? Или думаете можно в одну БД засунуть и регу и инфу? Окей... база так база ))

Aliance

Цитата

Почему?

тебе главное рега?
начать нужно хотя бы с проектирования БД.

Цитата(Opik @ 6.7.2005, 21:56)

тебе главное рега?

просто там есть непонятная для меня вещь...окей, БД есть. Что дальше? Нужно придумывать поля?
Я думаю из реги такие:
ник, мыло, пароль, статус
Из статей такие:
кол-во постов, кол-во комментариев и наверное и все?!

Aliance
подготовь полные SQL запросы создания таблиц для:
пользователей
групп
новостей/статей
категорий

Если верить ПХПМайАдмин, то вставка делается так:

Код

INSERT INTO `main` ( `nick` , `email` , `pass` , `status` , `posts` , `comments` , `id` )  VALUES ( 'Aliance', '[email protected]', 'password', '1', '0', '0', '0' );

Вот что получается: http://www.jsguide.spb.ru/TEST/login/index.php

Это сообщение отредактировал(а) Aliance - 6.7.2005, 23:06

Aliance
ты бы лучше структуру таблиц в студию.

1 БД (jsguider_articals)
1 Таблица пока что (main)
7 пока что полей (nick, email, pass, status, posts, comments, id)
nick - ник, TINYTEXT, полный текст
email - мыло, TEXT, полный текст
pass - пароль, TEXT, полный текст
status - статус, tinyint(3) UNSIGNED
posts - посты, int(10) UNSIGNED
comments - комменты, int(10) UNSIGNED
id - первичный ключ, AUTO_INCREMENT INT( 255 ) UNSIGNED

ну что ты как маленький? молча скинул:

Код

CREATE TABLE `main`...

Да и "пока что" лишнее.

Цитата(Opik @ 7.7.2005, 00:27)

Да и "пока что" лишнее.

Не извесно...

Цитата(Opik @ 7.7.2005, 00:27)

молча скинул

Не понял... зачем ее создавать, если она уже создана.

Aliance
я намекаю на:

Цитата

nick - ник, TINYTEXT, полный текст email - мыло, TEXT, полный текст pass - пароль, TEXT, полный текст status - статус, tinyint(3) UNSIGNED posts - посты, int(10) UNSIGNED comments - комменты, int(10) UNSIGNED

зачем это писать? просто скинул запрос. будет и так понятно, что где куда.

Ладно. Теперь, что - регистрацию?

Цитата

Aliance подготовь полные SQL запросы создания таблиц для: пользователей групп новостей/статей категорий

Добавлено @ 23:39
Да и статус - 1 или 0 - мало, нужны группы. ИМХО

Цитата(Opik @ 7.7.2005, 00:39)

Да и статус - 1 или 0 - мало, нужны группы. ИМХО

Admin и пользователи. Все. Кто еще-то?

Цитата(Opik @ 7.7.2005, 00:39)

подготовь полные SQL запросы создания таблиц для

Создания или заполнения? Создать можно в пхпмайадмин вручную, мне так понятнее. А заполнять пхп скриптом автоматом... так все же создания?

Aliance

Цитата

Admin и пользователи. Все. Кто еще-то?

редакторы, забанненые... и т.д.

Цитата

Создания или заполнения?

создания.

Цитата(Aliance @ 6.7.2005, 21:10)

Цитата(Bikutoru @ 6.7.2005, 19:45) участники могли редактировать Они вообще не будут их редактировать, иначе премодерация ни к чему. Представь, человек написал хорошую статью, я ее подтвердил, а он потом ее редактирует... И он может там написать что угодно... Не есть гут...

На самом деле я немного другое имел в виду. Я же писал, что редактировать можно только свои статьи. Если администратор отредатировал статью, то можно запоминать автора последнего изменения (не обязательно автора самой статьи), и, если его права выше прав владельца статьи, то не давать доступ. Можно предусмотреть запрет редактирования опубликованных статей.
Если же запретить редактирование вовсе, то авторы не смогут исправлять свои стилистические, орфографические и грамматические ошибки, это придется делать администратору, что очень затруднит его работу.

Цитата(Opik @ 7.7.2005, 08:52)

редакторы, забанненые... и т.д.

Нет, этого я не хочу

Цитата(Opik @ 7.7.2005, 08:52)

создания.

Зачем их создавать, я ж уже создал...не понимаю

Цитата(Bikutoru @ 7.7.2005, 10:47)

Если же запретить редактирование вовсе, то авторы не смогут исправлять свои стилистические, орфографические и грамматические ошибки, это придется делать администратору, что очень затруднит его работу.

Просто нужно пользоваться кнопкой предпросмотр!

Aliance

Цитата

Нет, этого я не хочу

ты не хочешь? или ситуация такая:
ты искал скрипт, ты его не нашел, ты решил что будет хорошо если тебе его напишут?

Цитата

Зачем их создавать, я ж уже создал...не понимаю

ты создал, а мы нет, нам непонятно. что и как.

Цитата(Opik @ 7.7.2005, 12:33)

ты искал скрипт, ты его не нашел, ты решил что будет хорошо если тебе его напишут?

Я его сам собрался писать, просто с вашей помощью.

Цитата(Opik @ 7.7.2005, 12:33)

ты создал, а мы нет, нам непонятно. что и как.

Я же кинул структуру таблицы. Что еще?

Aliance
просто ты не понял, про какой вид я говорил, достаточно просто:

Код

CREATE table `blablabla` .... type myisam;

и так далее. так понятнее, иногда объяснять (если тип enum) ну или по желанию :_)

Хорошо, это сделано (хоть и по другому). Теперь переходить к следующей части или все же сделать это как ты просишь?

лучше как я прошу. пож-та

Код

CREATE TABLE `main` (   `nick` tinytext NOT NULL,   `email` text NOT NULL,   `pass` text NOT NULL,   `status` tinyint(3) unsigned NOT NULL default '0',   `posts` int(10) unsigned NOT NULL default '0',   `comments` int(10) unsigned NOT NULL default '0',   `id` int(255) unsigned NOT NULL auto_increment,   PRIMARY KEY  (`id`),   FULLTEXT KEY `nick` (`nick`,`email`,`pass`) ) TYPE=MyISAM AUTO_INCREMENT=2 ;

Код

INSERT INTO `main` VALUES ('Aliance', '[email protected]', 'password', 1, 0, 0, 1);

Это сообщение отредактировал(а) Opik - 7.7.2005, 16:46

другое дело. тока пароль надо либо через password, либо через md5 делать.

Вот что я и хотел сделать (md5), забыл Исправлено. Что теперь, с этим все?

Тока не md5, а уж sha1

Mal Hack
почему?

md5 умер, вобщем коллизию нашли и обсуждалось это на форуме

Ок, не проблема. Давайте по делу?

Цитата(Aliance @ 7.7.2005, 18:04)

Что теперь, с этим все?

теперь таблицу самих статей, групп, группы - обязательно

Цитата(Opik @ 8.7.2005, 00:15)

теперь таблицу самих статей

Что туда должно входить? ID, собственно статья, раздел, комментарии - что-нибудь еще?

Группы зачем, их всего 2?

Aliance
говорю же - редакторы и т.д.
тебе не нужны? сейчас не нужны? а ведь вдруг понадобятся?

Для них отдельную таблицу? А что в ней будет хранится?

Aliance
все права которые есть, да, отдельной таблой.

Админ, Редактор, Пользователь, Гость. 4 маски.
Создаю таблицу и что 4 поля в ней? Тогд там должны хранится boolean?

Aliance
почему? хватит
enum('yes', 'no')
или
enum('1', '0')

Цитата(Opik @ 9.7.2005, 13:12)

enum('yes', 'no') или enum('1', '0')

Вот лично я с 0 и 1 путаюсь, а yes, no - длинно. В Инвижоне используется Y и N.

Вы меня запутали. Опик, объясни что должно хранится в этой таблице.

Mal Hack
в самой mysql у пользователей Y и N

Пока вы далеко не зашли!

Есле вы используете базу!
Тогда лучше есле статья будет в виде файла а ссылка храниться в базе на нее.
Тогда мы облегчим вес базы.
Как такой вариант?



Я уже работаю в полуручном варианте.
Админ еще не готов.

Проблемы были с защищеным режимом сервера.
Пришлось темы и разделы создавать в базе и генерить ссылку на файл.
Каталог с файлами придется защищать.

Мое мнение.
Пока

Спасибо, интересно.
А далеко мы не зашли потому что никто не пишет...по теме по крайней мере

Хы ) после написания регистрации пришло время вернутся к написанию данного скрипта - статей.

Опик, хочу извенится за все свои посты - прочитал их сейчас и ужаснулся. Понял как многово я тогда не знал и откровенно тупил 

Итак, регистрация у меня теперь есть. Она у меня с форума IPB.

Новый план: таблицы статей, таблица комментариев, таблица групп, таблица категорий. 

Aliance, 
я сейчас тоже почитал - улыбнуло , причем мои же больше всего.


скидывай дамп  посмотрим структуру ))))) 

Пример 1 еще неодобренной статьи с 1 комментарием:


Вот. Логин и группа будет братся из другой БД, она уже готова (БД форума IPB)
Пока возникают такие вопросы:
• что-то сделано не так?
• поля content заданы как varchar(255) - хватит ли этого? Если статья может быть на страницу. Может лучше BIGBLOB использовать?
• если вся статья скрыта, то на "скрытость" комментов должно быть все равно. Реально ли?
• не понимаю особого назначения 3 таблицы    

Это сообщение отредактировал(а) Aliance - 17.5.2006, 21:40

Aliance, ну во-первых, я бы вынес авторов в отдельную таблицу и связывал бы по id-ишникам, т.к. это у тебя сечас избыточная информация, затем, мне не понятно для чего это поле

имеет текстовый тип. Я так понимаю, оно должно иметь связь по id-ишнику с третьей таблице section.

в таблице `articals` тоже не уместно.
Поля дат, я бы перевел в тип INT(10) и загонял бы туда дату в формате unix-timestamp.
Таблица `articals_comments` - я вообще не вижу как она связана с основной таблицей статей, должно быть поле articleID, которое будет содержать ссылку на своего родителя, т.е. на статью.
Поля content я бы сделал тип TEXT. 

Я бы сделал так:
 

А я бы сделал как -=Ustas=-, но в том отличии, что поле content с типом TEXT вынес бы в отдельную таблицу и связал по ID
 

Так будет оптимальней? 

-=Ustas=-, 
Да, т.к для поля BLOB, TEXT не поддерживаются таблицами HEAP, грубо говоря выборка из таблиц, содержащих TEXT, BLOB идет при помощи файлов.

Добавлено @ 17:56 
А не в памяти, как у остальных, но тут много нюансов по сути есть. 

Ээ, а если так оставить? Мне так понятнее, во-первых. Во-вторых, зачем мне авторов в отдельную таблицу выносить-то? 

Можно  , если ты над собой издеваться любишь


Вот именно, это только ВО-ПЕРВЫХ, а далее ты будешь смотреть на эту структуру и сам с себя улыбаться.


В твоем подходе, это называется избыточной информацией. Смотри, создал ты 50 статей, в итоге у тебя получается 50 строк с 50-ью никами Aliance. А вдруг ты захотел поменять свой ник - тут тебе придется править его в 50-строках, вместо того, чтоб исправить в одном месте.
Это не рационально, использовать подобную структуру. 

Aliance, 
Есть понятнее, а есть правильнее и логичее, что потом, в итоге, станет понятнее первого.

Что лучше выбрать?  

Приблизительно так же реализована БД в IPB  Как у меня...
Ну да ладно, сделаю так 
Что далее писать нужно? Уже непосредственно само добавление статей? 

Aliance, 
Я думаю, было бы неплохо сделать модульное ядро для того, что будет. 
Т.е захотел то - подключил модуль и всё работает. На примере новостей. Тогда и проблем с расширяемостью быть не должно. 

Поясни? Возможно меня это не устроит, т.к. мой сайт итак уже работает на модулях. И статьи будут подключатся как domen.com/index.php?m=articals&... 

Aliance, 
ну примерно это же я и имел в виду. 

Гуд  Остается открытым вопрос:

 

Ну да, сначала нужно написать модуль для управления статьями, а затем уже модуль для публикации ноовостей. 

Тоесть админку?
Возможности:
• удалять статьи (админ+модер+автор)
• проверять и удобрять статьи (админ+модер)
• редактировать статьи (админ+модер+автор)
• управлять категориями/группами/масками доступа/всем остальным (админ)

Так?

ЗЫ: давайте не будем называть это новостями, это статьи  

Сорьки, оговорился  Да, именно админку. 

-=Ustas=-, 
Я админку обычно оставляю на потом ))

Aliance, 
ну пока так, если начинаешь с админки. Но чем управлять если ничего нету? (Это моя логика) 

Не согласен  Сначала надо структуру и управляющий элемент продумать и сделать, а вывод и публикацию это уже раз плюнуть... 

-=Ustas=-, 
насчет структуры я согласен.
в остальном - кому как нравится. 

Opik, ну вот смотри, спроектировали мы структуру, и что, начинаем делать пользовательскую часть, т.е. интерфейс для посетителей, а данные для тестов вносить постоянно через консоль или phpmyadmin-а ?!  

-=Ustas=-, 
Это долго? )
хватит нам уже флудить не по теме. 

я тоже так согласен  и все же, с чего начинать?
В админке я максимум что напишу - ее общий вид. Ибо как я могу написать, скажем, редактирование статей если ниодной статьи нет