1 761 Відповідь від ktretyak

(4 відповідей, залишених у HTML та CSS)

Singularity, дякую. Вигляд вже "те що треба", але очевидно, що є якісь дефолтні відступни з якими простим margin: 0px; не справитись. Чомусь така кнопка пірнає під рядок. Безуспішно пробував сказати display: inline-block;

Перейти до форуму: HTML та CSS

1 762 Тема від ktretyak

(4 відповідей, залишених у HTML та CSS)

Оскільки я хочу, щоб при кліку на об'єкті обов'язково відправлявся POST запит, причому без використання JavaScript, то в мене не залишається іншого вибору як використовувати кнопки форми
[code=html]
<button type="submit">Відправити</button>
<!-- або -->
<input type="submit" value="Відправити" />
[/code]
Проблема в тому, що дефолтна стилізація точно не вписується у той контекст, де їх потрібно розміщувати.

Дуже добре було б стилізувати їх так, щоб вони в результаті мали вигляд простого лінка. Не підкажете як це зробити з мінімальними зусиллями, але без використання CSS фреймворка Bootstrap (в даному випадку його підключення "поламає" всю малину)

Перейти до форуму: HTML та CSS

1 763 Відповідь від ktretyak

(12 відповідей, залишених у PHP)

koala написав:

Одна таблиця - групи користувачів. Друга таблиця - дозволи груп в ресурсів. Що тут важкого чи складного?

Так, якщо дотримуватись ваших рекомендацій, що роздавати права лише групам, а не конкретним користувачам, то і записів буде значно менше...
Я поки що вагаюсь

Перейти до форуму: PHP

1 764 Відповідь від ktretyak

(12 відповідей, залишених у PHP)

Та да, облом досить швидко прийшов, коли я подумав, наприклад, про виведення списку всіх тем, до яких користувач має доступ. І в разі коли притримуватись ідеї "всі доступи в одному масиві", то я уявляю скільки треба буде проставити
[code=sql]
OR WHERE permission_view_theme in(1, 2, 3 ...)
...
[/code]
Повертаюсь назад до таблиць =)

Перейти до форуму: PHP

1 765 Відповідь від ktretyak

(12 відповідей, залишених у PHP)

Я оце зараз подумую чи не серіалізувати просто масив доступів кожного користувача і чи не вставити його потім в окреме поле в таблиці користувачів.
Переваги - не потрібно створювати окремі таблиці, які можуть мати дуже велику кількість записів.
Недолік - якщо користувач матиме велику кількість різних доступів, то "тягання їх за собою" відповідно зменшуватиме оперативку. Ну і відновлювати цей масив а потім парсити теж ресурсоємна справа. Хоча... скільки там кожен користувач матиме тих доступів, можливо максимум пару сотень.
Спробую

Перейти до форуму: PHP

1 766 Відповідь від ktretyak

(12 відповідей, залишених у PHP)

Головне питання не в тому які опції можна буде проставити для користувача, для груп, для решти. Головне як реалізовувати перевірку будь-яких прав, враховуючи, що користувачів може бути десятки тисяч, і кожен з них може мати десятки чи й сотні прав в залежності від підписок на різні теми, причому для кожної теми права можуть бути різними (view, insert, update,delete...).

Підхід який є у *nix системах можна реалізувати, якщо кожен об'єкт матиме властивості, де можна прописати ці права. А тепер, увага, питання - Як це зробити? Створювати аналог властивостей для кожної окремої теми, та записувати туди всі ці права? Мабуть десятки тисяч таблиць, це буде...

Короче думаю, що треба АБО робити звичайні ролі/права, які є на більшості форумів і не паритись з реалізацією задуманого форума-монстра, АБО все-таки створювати всі ці множинні опції складати їх в одну-дві таблиці і просто оптимізовувати запити в БД до них.

Перейти до форуму: PHP

1 767 Відповідь від ktretyak

(12 відповідей, залишених у PHP)

Дякую колеги, але я хочу створювати не статичні сторінки і каталоги, а віртуальні. Мабуть в такому разі права *NIX доступів не прокатять. Так же?

Перейти до форуму: PHP

1 768 Тема від ktretyak

(12 відповідей, залишених у PHP)

На даний момент я створюю самописний форум на основі KohanaFramework.
В якості самоосвіти, пробую створити досить складний проект, де буде багато різних налаштувань, зокрема і по правам доступів.

В зв'язку із цим в мене питання до тих, хто сам реалізовував складні проекти. Як краще організовувати перевірку прав доступів. Заплановано реалізувати і ролі, і окремі права. Перше, що спадає на думку - зробити таблицю, в якій буде ідентифікатор користувачів, та ідентифікатор відповідного об'єкта, а також визначені конкретні права (insert, update, delete...).

Але якщо це буде одна таблиця, то при збільшенні в ній записів до десятків тисяч, вона буде досить "важкою" для роботи форума. Це по-перше, ну а по друге - більшість тем мабуть все ж будуть доступними для всіх користувачів і вносити їх всіх в таблицю доступів немає сенсу. Тобто якось треба спочатку перевіряти чи дана тема видима для всіх, і якщо ні, то перевіряти хто саме має на це право. Для цього мабуть треба використовувати окрему таблицю...

Як я і написав в назві теми - бажано не просто оптимізувати велику кількість дозволів, а ще й дати можливість визначати права строго через адмінку (а не через код програми). Доречі цікаво чи прийнято через адмінку встановлювати налаштування, які будуть записані не в БД, а у файл.

Перейти до форуму: PHP

1 769 Відповідь від ktretyak

(9 відповідей, залишених у PHP)

Краще намагатись читати офіційну документацію (хоч і на англійській), ніж сторонні ресурси. PHP має досить добру документацію.

Стосовно вашого запита, то, по-перше, у вас намішано процедурний і об'єктний стиль застосування MySQL, що строго не рекомендується. Якщо ви тільки починаєте вивчати PHP, то краще вже починати із об'єктного стилю кодування.
Якщо у вас не виходить використовувати md5, то можливо ви вставляєте в БД не результат приведення паролю до "md5 вигляду", а пробуєте вставляти і витягувати текстовий пароль...

П.С. Можливо у вас далі закривається з'єднання з БД (що є обов'язковим при використанні MySQLi, але в наведеному прикладі покищо цього не видно).

Перейти до форуму: PHP

1 770 Відповідь від ktretyak

(9 відповідей, залишених у PHP)

Vo_Vik написав:

А юзер від якого конектитесь в PHP мав права на доступ до потрібних табличок?

Так мав. При UPDATE повертався результат, що успішно все оновилось.

В мене був запит з декількома рівнями підзапитів. І здається я трохи був лоханувся із розміщенням псевдозапиту типу
[code=sql](SELECT @r:=0) AS foo[/code]
Мені його треба було розмістити разом із тим запитом, який використовує глобальну змінну MySQL @r. Але спочатку я цього не зробив. І коли тестував це все діло в редакторі MySQL, то змінна не обнулялась, бо вона закріплялась за поточною сесією (в редакторі сесія видаляється як у браузера - після його закриття). Ну і, як ви розумієте, коли я тестував запити вже через PHP, то не використовувалось постійне з'єднання із БД, а тому змінні обнулялись...
Такі справи.

Перейти до форуму: PHP

1 771 Відповідь від ktretyak

(9 відповідей, залишених у PHP)

funivan написав:

спробуйте в консолі, можливо трабли з вашим редактором)

Ні, редактор працює як належить. Він може хіба що тільки "падати" інколи. Доречі, я працюю на Windows і використовую HeidiSQL.
Між іншим - по юзабіліті він є найкращим безкоштовним редактором, на якому мені доводилось працювати.

Перейти до форуму: PHP

1 772 Відповідь від ktretyak

(1 відповідей, залишених у Інше)

Останнім часом я повністю перейшов на Twitter. Там мабуть представлено більшу половину всіх сайтів новин та інших інтернет ресурсів з усього світу.

Реєструєтесь там. Знаходите цікавий ресурс, підписуєтесь на нього, та переходите на головну сторінку. Після чого вам буде надходити свіжа інфа без перезавантаження сторінки.
По суті в Twitter йде потік одних лише заголовків, з яких можна переходити вже на відповідний ресурс і читати його повністю.

По-ідеї, якщо ви зареєструєтесь, то вам повинно стати доступним перегляд, наприклад, моєї підписки. Можете щось собі вибрати із цього.

Перейти до форуму: Інше

1 773 Відповідь від ktretyak

(9 відповідей, залишених у PHP)

Є ще один очевидний варіант для вирішення цієї задачі - створити темпову таблицю з auto_increment, потім заінсертити в неї всі потрібні значення, по яким буде відбуватись JOIN, ну і потім вже робити UPDATE. Але це мабуть все-таки костиль, а не нормальне рішення.

Оновлено:
Тю, нічого не розумію. Коли роблю простий селект із зазначеним ітератором, то насправді все чудово працює і з подачі PHP до MySQL. Але коли роблю JOIN, то працює некоректно - ітератор видає лише одиницю, тобто значення глобальної змінної  MySQL скидається по якісь причині.

Оновлено:
Трохи переписав запит, то запрацювало вже коректно і в PHP. Але ж дивно, що старий запит працював лише в MySQL. Я так і не зрозумів чому...

Перейти до форуму: PHP

1 774 Відповідь від ktretyak

(9 відповідей, залишених у PHP)

Replace написав:

Мабуть мається на увазі отримати для кожного рядка порядковий номер. Я би такі штуки краще робив в PHP, що і вам рекомендую зробити.

Дякую. Я так би і робив, якщо б результати запита мені треба було виводити в PHP. Але на даний момент в мене задача стоїть щоб зробити JOIN із таким селектом, а потім зробити UPDATE.
Думаю тут процедурою можна обійтись, але це трохи менш бажаний варіант.

Перейти до форуму: PHP

1 775 Тема від ktretyak

(9 відповідей, залишених у PHP)

За допомогою редактора MySQL (доречі, не phpMyAdmin) справно працює запит типу
[code=mysql]
SELECT
    @i:=@i+1 AS iterator,
    t.*
FROM
    tablename AS t,
    (SELECT @i:=0) AS foo
[/code]
Цей спосіб застосовується для лічильника рядків. Але він не хоче коректно працювати в запиті, який я пишу в PHP.
Ніхто не в курсі як це обійти?

Перейти до форуму: PHP

1 776 Відповідь від ktretyak

(8 відповідей, залишених у Системи керування контентом)

Replace написав:

Як такого кешування немає. Створюється лише кеш файлів, для того щоб кожного разу не лізти в базу за кодом певного модуля.

Але я спостерігаю, що при першому завантаженні певної сторінки, вона завантажується, скажімо, 150 мс, а вже при другому завантаженні в двічі швидше. Оскільки я не побачив кеш-файлів не в каталозі cache, ні в каталозі PHP для кешу, то припускаю, що кешування відбувається на рівні запитів MySQL, тобто це не стосується самого PunBB.

Перейти до форуму: Системи керування контентом

1 777 Відповідь від ktretyak

(8 відповідей, залишених у Системи керування контентом)

Для теста поставив собі forum на PunBB.
Бачу, що код написано ще без класів, тобто мабуть з масштабуванням буде не так все легко, коли захочеться на нього понакручувати купу примочок...
Тим не менше, але форум не працює, а літає. От мені цікаво це він так швидко працює із кешуванням, чи ні. Покищо ніде не побачив в налаштуваннях, що можна увімкнути/вимкнути кешування. Бачу лише, що каталог cache є, але там схоже лише конфіг-файли для кешування.
Ніхто не знає як перевірити чи форум працює із кешуванням?

Перейти до форуму: Системи керування контентом

1 778 Відповідь від ktretyak

(10 відповідей, залишених у PHP)

Chemist-i написав:

..Логічне "і"...

Ні, я пробував - вставляти and то видає інші результати

Перейти до форуму: PHP

1 779 Тема від ktretyak

(10 відповідей, залишених у PHP)

Може хтось в курсі як пояснити роль амперсанда, який стоїть перед цифрою? Наприклад, якщо у наступному виразі вписувати в значення $var парні значення, то будемо отримувати нуль, якщо непарні - одиницю:
[code=php]$var = 3;
var_dump($var & 1); [/code]

Перейти до форуму: PHP

1 780 Відповідь від ktretyak

(77 відповідей, залишених у Обговорення)

truesupport написав:

В мене також є ідея, хоча це здається не моя але вона мені дуже сподобалась.
Сайт каталог майстрів (шпалери поклеїти плитку в ванні положити), де можна добаляти майстрів залишати коментарії про їх роботу, рейтинг, фотографїї з резльтатами роботи і все таке інше. Просто мені здається що зараз люди шукають майстрів або через знайомих або через ваш магазин. А якби був такий ресур їм би було простіше. Плюс майстрам ще одне місце де вони можуть написати. Петро Равшанович - плиточник, майже не пю, або щось подібне.

В мене є досить легкозапам'ятовуюча назва домену http://dostupno.kyiv.ua. Цей сайт планую використовувати для подібних цілей, які прозвучали у вашій ідеї.

Поки що розмістив лише табличку із цінами, бо ще не маю своїх фоток виконаних робіт (чужі фото, що вже опубліковані в інтернеті розміщувати якось не хочу).
Ну і плюс, я ще поганенько верстаю сайти (маю покищо невеликий досвід лише в програмуванні бекенда).

Перейти до форуму: Обговорення