Szukam prostego, ładnego i fajnego CMS'a...
[PHP][CMS] "Przyjazne linki" - implementacja
[CMS] Newsy i grupowanie - tagi?
[PHP] CMS i szablony - jak połączyć?
Idealny CMS - jaki powinien być?
Paradygmat tworzenia CMS
Ankieta- trener wszechczasów siatki w ozo
Automatyczna analiza ankiety w ?
Mikołaj ma w tym roku dla Ciebie dużą niespodziankę!
jak podlaczyc filtr paliwa do puga 1.9 TD ??
chomiki
1. Komentowanie zawartościA. Pod komentowaną pozycją
Czyli pod artykułem, newsem, itd... i poprzednimi komentarzami. Zaletą jest to, że nikt nie skomentuje pozycji, jeśli nie istnieje lub jest wyłączona. Uwaga: gdy ADMIN wyłączy element podczas gdy USER będzie go komentował (co nie powinno się raczej zdarzyć, ale może), USER straci treść (można zastosować jakieś alternatywne wyjście).
B. Na osobnej podstronie
Z jednej strony nie trzeba ładować za każdym razem artykułu oraz poprzednich komentarzy, gdy np. klikamy "Podgląd", a z drugiej - trudniej sprawdzić, czy pozycja jest włączona i czy istnieje (rozważmy też to, że rozszerzenia także mogą wykorzystywać moduł komentarzy, a wtedy nie znamy np. nazw tabel i ich struktury).
C. Odpowiedź A + AJAX
Formularz jest pobierany za pomocą AJAX na żądanie. Nie każdy będzie komentował, a gdy obsługa BBCode jest włączona, trzeba załadować edytor: editor.js oraz ikony. A jeśli użytkownik ma wyłączoną obsługę JavaScript? Pozostaje przejść na osobną podstronę (B) lub ładować podstawowy formularz (A) albo... odświeżyć wszystko - np. artykuł + poprzednie komentarze, tylko do tego dołożyć formularz zamiast linku "Dodaj komentarz".
2. Edycja zdjęcia lub awataru w profilu użytkownika
A. Tam, gdzie pozostałe informacje
Na przykład pod informacjami dodatkowymi, a powyżej pola "O sobie". Ewentualnie pod "O sobie" w oddzielnym nagłówku.
B. Na osobnej podstronie
Tylko gdzie umieścić link do tej podstrony?
C. Odpowiedź A, tylko w innej zakładce
Do zrealizowania, tylko dochodzi znów problem użytkowników bez obsługi JS.
3. Zmiana daty artykułów, newsów, itd.
A. Nie potrzeba zmieniać dat
B. Za pomocą kalendarza w JavaScript
C. Za pomocą pola "datetime" albo "date" i "time" (tylko Opera)
D. Pola <select>
4. Statystyki dotyczące treści
Jakieś pomysły?
Wypełnijcie ankietę. Jeśli odpowiedzi są oznakowane literami, podajcie tylko literę.
1. C
2. A
1. C
2. A
3. B
1. Na pewno będzie AJAX, czyli C. W przypadku braku obsługi JavaScript - nie odpowiada ani A, ani B. Prawdopodobnie zostanie tak, jak jest (B), aby nie doszło do konfliktów między szablonami i nagłej utraty treści w przypadku wyłączenia artykułu, zaś problem "bezpańskich komentarzy" rozwiążę w inny sposób.
2. Jeśli wprowadzę galerię emblematów lub galerię zdjęć wysyłanych przez użytkowników, pozostaje B (ew. C). Co o tym sądzicie?
3. Najpowszechniejsza opinia = B. W przypadku braku JS - może D.
Jakieś uwagi, sugestie, opinie? Co jeszcze proponujecie?
WebCM, dzisiaj rzadko kto wyłącza JS! Jeżeli ktoś ma być do przodu, to napewno go nie wyłączy! kiedyś tak było, dzisiaj nikt nie wyłącza, bo internet poszedł do przodu ("Web 2.0")
Ale strona powinna być czytelna i hmm... używalna z wyłączonym JS. Pisał o tym kiedyś riddle (Piotr Petrus) - http://perfectionorvanity...cza-javascript/
Dorzucę jeszcze kilka pytań i liczę na dużą frekwencję.
5. Czy wyświetlać zawsze awatar użytkownika?
A. NIE - to nie ma sensu - dodatkowe żądanie, więcej KB do przesłania...
B. TAK - w menu "Użytkownik"
C. TAK - w innym miejscu (gdzie?)
6. Prywatne galerie użytkowników
Każdy użytkownik miałby prywatną galerię. Wybrane zdjęcie stałoby się znakiem rozpoznawczym. System automatycznie tworzyłby miniaturki. Możliwość dodania zewnętrznych obrazów z URL.
A. TAK - to przyciągnie użytkowników skryptu
B. NIE - to zbędna funkcja
7. Uprawnienia użytkowników (np. do edycji kategorii X lub do panelu admina)
Powinny być:
A. Nadawane poszczególnym użytkownikom
B. Nadawane grupom użytkowników
8. Galeria awatarów
A. TAK - do włączenia w panelu admina
B. NIE - to zbędna rzecz
Odpowiedzcie na pytania - najlepiej z uzasadnieniem odpowiedzi.
Jeśli chodzi o JS to w niektórych instytucjach dla bezpieczeństwa może być wyłączony. Może ktoś korzysta z nietypowej przeglądarki, która nie obsługuje wszystkich funkcji? Albo z tekstowej na starym kompie?
5. B (ale w opcjach profilu możliwość wyłączenia pokazywania awatarów, np. user "x" i "y" mają awatary, a user "z" ma wolne łącze - w UCP może wyłączyć)
6. A - domyślnie wyłączone, zezwolenie na jeden awatar, do włączenia w ACP (żadnych zdjęć, to nie fotogaleria!)
7. A lub B (w ACP ustawienia kategorii: dostęp [radio: dla użytkowników; dla grupy])
8. Inna propozycja: galeria gotowych awatarów, który można sobie wybrać (jak w IPB)
Sorry, ze od pyt 5 ale tak..
5 – C, niech się pyta podczas instalowania skryptu, jak ktos oszczędny w KB wybierze sobie dla siebie opcie… no i w PA nieh będzie wybor…
6 – A, uzasadniam… bo to jest jak w tej akcji „bo zupa była za słona”, chodzi mi o to, ze ktoś kto chciałby przeznaczyć skrypt na jakis portal dla fotografów, fajna taka opcja.
Tez proponuje w PA dawać taką możliwość wyboru przez admina
7 – C, nie ma takiego wyboru… ale uważam, że dzisiaj Cisy sa na tyle rozwinięte, ze obje opcje są dobre…
8 – A, tak jak w pytaniu 5, uzasadnienie jest podobne
Ad 2. A - Na razie jest prymitywna obsługa awatarów - tylko upload, ale to chyba wystarczy. W panelu admina można ustawić dowolny obraz.
Ad 5. Są różne opinie. Na razie A.
Ad 6. Różne opinie. Prywatne galerie awatarów raczej nie ma sensu, chyba że ktoś umieszczałby znaczki pocztowe. Zastanowię się nad galerią zdjęć osobistych, ale prawdopodobnie będzie to rozszerzenie, niezwiązane z awatarami.
Ad 8. Chodzi o galerię gotowych awatarów jak w IPB lub PhpBB. Wybór zostawiam na później, chociaż większość wgrywa własne obrazy. Chociaż może być tak, że użytkownicy wybierają z galerii awatar związany np. z ich zainteresowaniami i nie mogą wgrać własnego dla bezpieczeństwa lub z innych powodów. Wracając do implementacji - może nie ma sensu tworzyć osobnej podstrony, aby wybrać zdjęcie z galerii, prawda?
Dodam jeszcze pytanie:
9. Lista zarejestrowanych osób on-line + boty
A. Wyświetlać zawsze
B. Wyświetlać, jeśli włączymy opcję w panelu admina
C. Nie wyświetlać
9. B, chociaż ja mam na stałe zrobioną listę użytkowników
10. Czy przejść na kodowanie UTF-8?
Aktualnie zawartość jest kodowana ISO-8859-2. Przejście na UTF-8 umożliwi wstawianie znaków specjalnych bez encji (np. ®) i rozwiąże problem z przesyłaniem danych na serwer za pomocą AJAX, lecz znaki alfabetów niełacińskich i diakrytyczne (ą, ś, ć...) zajmują po 2 bajty.
ISO-8859-2
UTF-8
11. Czy rozszerzenia powinny trzymać swoje pliki tylko w swoim folderze?
A. TAK - czyli pliki językowe, szablony, itd. znajdują się w katalogu rozszerzenia, np. plugins/guestbook
B. NIE - czyli szablony mogą znajdować się np. w katalogu style/guestbook, style/admin, pliki językowe w lang...
Znów powrócił problem ścieżek do szablonów. Aktualnie definiuję ścieżkę systemową jako stałą SKIN_DIR oraz ścieżkę opcjonalną $content->dir. Jeżeli pliku szablonu, który trzeba dołączyć, nie ma w $content->dir, wtedy system szuka go w SKIN_DIR. Panel admina ustawia własną (style/admin), więc wyświetlenie szablonów rozszerzeń w PA jest niemożliwe.
Powiedzmy, że rozszerzenie w panelu admina ustawia $content->dir na plugins/guestbook/. System szuka tam pliku guestbookAdmin.html i go znajduje. Potem trzeba wyświetlić szablon panelu admina - szuka w plugins/guestbook - nie ma. Szuka więc w katalogu domyślnym - SKIN_DIR - nie ma. Nie wiem, czy dalej kombinować w klasie Content i stworzyć możliwość ustawiania nieskończonej ilości możliwych katalogów, czy dodać kolejny warunek, aby szukał w katalogu "admin"... Czy po prostu porozrzucać pliki rozszerzenia do różnych katalogów - wtedy problemu nie będzie.
10. tak, jeżeli chcesz skrypt rozpowszechnić, to dobrze by było, żeby można było pisać po chińsku i cyrlicą
10. Tak, czas przejść.
11. A. Joomla wykorzystuje wariant B i przez to jakiekolwiek zmiany w kodzie są praktycznie nie do przejścia.
Przeszedłem na UTF-8. Problem 11 postaram się rozwiązać - większość jest za A.
12. Skórka panelu admina
Aktualnie wszystkie szablony panelu admina trzymam w osobnym katalogu - style/admin, w tym główny szablon admin.html. Jest on uzależniony od wybranej w ustawieniach skórki, np. default (style/default). Korzysta z klas zdefiniowanych w style/nazwa_skorki/X.css. Jeżeli zmienimy skórkę na taką, która ma całkowicie inną budowę, układ graficzny i używa innych klas CSS, pojawia się problem - układ graficzny w panelu admina może rozsypać się.
A. Przenieś pliki admin.html i admin.css do katalogu głównej skórki - style/nazwa_skorki. Style będą mogły zmienić układ graficzny panelu administracyjnego, ikonki w menu i być może inne elementy. Od razu rozwiąże się problem 11, bo w przypadku wyświetlania modułów administracyjnych rozszerzeń nie będą wykorzystywane szablony z katalogu style/admin - nie trzeba definiować wielu ścieżek.
B. Nic nie zmieniaj.
C. Oddziel całkowicie skórkę panelu admina od wybranej skórki głównej. To oznacza, że trzeba zdefiniować osobne style CSS.
W przypadku B i C wciąż pozostaje do rozwiązania problem 11.
13. Graficzne menu
A. Pozwól ustawić ikonki lub klasy dla pozycji menu nawigacyjnego.
B. Niech webmasterzy tworzą niezależne menu od standardowego - będą mieć ikony, jeśli chcą.
C. Zostaw na razie menu tekstowe, a potem stwórz rozszerzenie do tworzenia menu graficznego
D. Zostaw menu tekstowe. Zbyt wiele grafiki obciąża serwer (trzeba pobrać wiele plików).
Użytkownicy domagają się menu graficznego - choć tak w ogóle są gdziekolwiek stosowane osobne ikony dla każdego linku? Zapytam więc Was, jak to widzicie.
12. C - Dlaczego? Pisałem DSF-a i skórka PA była zmienna, w zależności od używanej na forum (wbudowana w katalogu danego stylu). Potem były przez to same problemy. A tak, możesz zrobić dobrą skórkę dla PA i osobną dla stron użytkownika
moim zdaniem PA, pownien mieć swoje menu i nie zawracac sobei glowy skórkami w panelu
Ostatnie wyniki: 12 A (tak zdecydowali użytkownicy i problem zniknął), 13 (niski priorytet)
14. Kanały RSS
Nie mam jednej koncepcji, która okazałaby się najlepszym wyjściem. Może pomożecie w dokonaniu słusznego wyboru. Nowa wersja CMS będzie obsługiwać kanały RSS, tylko właśnie... nie chcę skomplikować kodu ani interfejsu, ale zaoferować korzystne rozwiązanie.
A. Niech będzie tylko 1 kanał RSS dla każdego języka, zawierający określoną ilość nowości.
Admin może wyłączyć tworzenie RSS-ów w ustawieniach systemu. Nie będzie oddzielnego modułu RSS w panelu admina.
B. Niech admin tworzy tyle kanałów RSS, ile chce, ale tylko dla nowości.
Panel admina zawiera dodatkową podstronę - RSS. Można tworzyć dowolną ilość kanałów. Tutaj znowu są różne warianty:
B1. Admin może wybrać tylko 1 kategorię, z której newsy będą trafiać do plików RSS albo opcję "wszystkie nowości" (wszystkie newsy trafią do RSS).
Zalety:
+ uproszczony interfejs
+ w bazie danych będzie tylko 1 wartość liczbowa
Wady:
- nie można wybrać np. 2 określonych kategorii
B2. Admin może wybrać wiele kategorii lub opcję "wszystkie nowości"
Zalety:
+ możliwość wyboru wielu kategorii (tylko określonych przez admina)
Wady:
- nie można w bazie zapisać wartości numerycznej - trzeba oddzielić ID kategorii przecinkami, co jest sprzeczne z zasadami normalizacji; ewentualnie stworzyć nową tabelę dla powiązań ID-RSS | ID-Kategorii
C. Podobnie jak w B, ale dla wszystkich typów kategorii.
Zalety:
+ więcej możliwości
Wady:
- więcej operacji podczas tworzenia RSS (np. wyciąganie informacji o typie kategorii, dołączanie types.ini), gdyż każdy typ ma własną tabelę, np. arts, files, links, news...
W przypadku C2: Jeżeli admin wybierze kilka kategorii RÓŻNYCH typów... Taka sytuacja jest też możliwa. Chyba trzeba to umożliwić i bardziej skomplikować kod.
(podpunkty takie same jak w punkcie B)
15. Statusy komunikatorów
A. Ikony statusów jako tło w CSS zamiast <img> - TAK / NIE
B. Link GG powinien prowadzić do serwisu MojaGeneracja - TAK / NIE / ZALEŻY
Odpowiadajcie.
14. Nie wgłębiałem się, ale admin może wybrać do RSS wszystkie najnowsze newsy (oczywiście każdy dostępny język) lub poszczególną kategorię.
15B - NIE!! Dlaczego? Pomyśl, dlaczego przesiadłem się na Jabbera
1. C
2. A
3. B / D
4. Czytane newsy - przedstawione na wykresach; które arty są na TOP, itd?
5. A (niech będzie wybór w PA)
6. B (jak ktoś chce sobie zdjęcie trzymać to niech trzyma u siebie na serwerze)
7. A (lub A i B - w zależności od typu witryny)
8. B (jak ktoś chce awatar to sobie wrzuci)
9. B
10. TAK
11. A (jeżeli dotyczy to TYLKO rozszerzenia)
12. A
13. ~ ?
14. B2
15. A TAK; B NIE
Wynik:
* 14 - rozstrzygnie się niebawem
* 15 A (TAK - przynajmniej na razie) B (NIE - ostatecznie wprowadzę opcję, gdy będzie popyt)
Już być może ostatnie pytania do ankiety - tym razem otwarte.
16. RSS - ciąg dalszy
Pisałem już o tym na forum KŚE. Mam jeszcze inne wizje. Przedstawię je tutaj:
A. Użytkownik decyduje, co chce otrzymywać w czytniku RSS. Może tworzyć swoje prywatne kanały (albo ma tylko 1). Pliki .xml NIE są zapisywane na dysku przy dokonywaniu zmian w treści (nawet dla 1000 userów wygenerować 1000 RSS-ów - to może chwilę potrwać), lecz generowane w locie. Ewentualnie można tworzyć cache na serwerze. Informacje o preferencjach RSS użytkowników są trzymane w bazie danych.
Zalety:
+ Użytkownik sam wybiera interesujące go tematy (czyt. kategorie)
+ Zawsze aktualne dane (albo trochę nieaktualne, gdy jest cache)
Wady:
- Większe obciążenie serwera - każde żądanie prowadzi do pliku .php
- Wygenerowanie XML i odczyt danych z bazy może chwilę potrwać przy dużym ruchu (choć i tak krócej niż wygenerowanie całej strony, np. strony głównej, widoku kategorii, profilu użytkownika...)
B. Każda kategoria ma swój kanał RSS. Może też istnieć ogólny RSS z wszystkimi newsami. Wtedy dodatkowa podstrona RSS w panelu admina jest niepotrzebna (admin nie tworzy własnych kanałów). Są jedynie ogólne ustawienia RSS-ów (można je też w ogóle wyłączyć).
B1. Czytniki kierują żądanie do gotowego pliku .xml, który jest odświeżany po zmianach treści
B2. Czytniki kierują żądanie do pliku .php, który generuje XML lub wczytuje go z cache
C. Admin sam tworzy kanały RSS i decyduje, z których kategorii mają pojawiać się newsy (lub inne typy zawartości). RSS-y są odświeżane po zmianach, więc czytnik kieruje żądanie bezpośrednio do pliku .xml. Więcej informacji w pytaniu nr 14.
Jak widzicie implementację RSS w systemie CMS? Co sądzicie o powyższych wizjach?
Czyli walka między obciążeniem serwera a innowacjami. Wariant A przyda się w praktyce tylko w rozbudowanych serwisach, w których pojawia się dużo treści, ale przycisk "Subskrybuj kanał RSS użytkownika" jest raczej niespotykany Za to w przypadku C pliki .xml można pobierać błyskawicznie, nie męcząc serwera.
17. Data urodzenia
Wprowadziłem pole JABBER do profilu użytkownika. Może jeszcze brakować daty urodzenia. Czy rzeczywiście przyda się w praktyce? Na razie nie ma powiadamiania o urodzinach, a stron 18+ nie będzie. Jednak wiedząc, ile kto ma lat, można zawrzeć bliższe znajomości (a może skutek będzie przeciwny), zorientować się, w jakim wieku najwięcej internautów odwiedza serwis (chociaż lepiej przeprowadzić ankietę, bo zagłosują też goście). O przydatności pola DATA URODZENIA zdecydujcie sami:
A. Zdecydowanie TAK - pole jest potrzebne
B. TAK - ale po włączeniu opcji w panelu admina
C. NIE - pole jest niepotrzebne
Nie spotkałem jeszcze forum lub serwisu, w którym jest powiadamianie o imieninach. Może wprowadzić taką funkcję?
bezsens, to nie NK - zarówno profilu jabbera jak gg oraz skype jest wiek - jak ktoś jest ciekawski to i tak do tego dojdzie
Co do RSS to nie wiem, ale zrobić tak żeby było dobrze zarówno dla użytkowników jak i serwera na którym stoi witryna
17. Data urodzenia
Moim zdaniem pole totalnie zbędne.
18. Nowy system skórek
Czy podoba ci się nowy system skórek? Cechy:
- wykorzystuje język szablonowy zamiast kodu PHP
- pozwala na modyfikację wyglądu wszystkich podstron
- zawiera dużo plików, obecnie 50 plików, w tym 45 szablonów
Przykład: http://code.google.com/p/...S/style/default
A. TAK - wszystko mi się podoba
B. Jest zbyt dużo plików - niektóre trzeba usunąć lub przenieść (które?)
C. Język szablonowy jest za trudny lub kod zbyt nieczytelny
D. NIE podoba mi się - inaczej bym to zrobił (jak?)
19. Czy Panel Redaktora powinien być oddzielony od Panelu Administratora?
Wyjaśnijmy pojęcia. W wersji 2009 wprowadziłem Panel Redaktora z dostępem dla redaktorów. Można dodawać / edytować artykuły, pliki, obrazy, linki i newsy, a także moderować komentarze. Panel Admina z dostępem dla administratorów umożliwia zmianę ustawień, kategorii, ankiet, rozszerzeń, użytkowników, grup, RSS, wolnych stron...
Panel Admina: http://dhost.info/compmaster/img/zrzuty/bloki.png
Panel Redaktora: http://yfrog.com/j930784871p
A. TAK - jest dobrze. Panele powinny być rozdzielone.
B. NIE - zarządzanie treścią powinno odbywać się w panelu admina jak w wersji 2.1
C. Mam inny pomysł - jaki?
20. Pytanie powiązane - czy podczas edycji lub dodawania treści chcesz widzieć panele menu (które są włączone w serwisie), aby mieć łatwy dostęp do kategorii i innych artykułów, newsów, itd?
A. TAK - chcę widzieć bloki menu z linkami (czyli edytować treść z poziomu serwisu)
B. NIE - wolę edytować treść w odizolowanym środowisku (czyli z panelu admina)
C. Mam inny pomysł - jaki?
21. Czy adresy URL powinny zawierać słowa kluczowe (tytuły obiektów)?
Bez słów kluczowych: strona.pl/art/99
Ze słowami kluczowymi: strona.pl/art/99-jak-zainstalowac-linuksa
A. TAK - powinny zawierać słowa kluczowe
B. NIE - adresy będą za długie
C. W zależności od ustawień
--- pytania nieobowiązkowe dla tych, którzy nie testowali F3Site ---
22. Czy aktualny układ panelu administracyjnego dezorientuje nowych użytkowników?
Napisz, co należy zmienić, aby poprawić użyteczność i prostotę obsługi.
A. TAK
B. NIE
23. Flagi i górne menu - aktualnie trzeba je modyfikować ręcznie w body.html
A. To mi odpowiada, a niepotrzebne języki usunę przed instalacją CMS-a
B. Wolałbym edytować górne menu w panelu admina
C. Wolałbym wybrać w panelu admina języki, które chcę używać
D. Mam inny pomysł - jak byś to rozwiązał(a)?
Mimo wszystko zachęcam do wypełnienia ankiety o F3Site. Jest 20 pytań, ale wszystko potrwa tylko kilka minut, gdyż większość pytań jest zamknięta (ABCD), zaś opisowe są nieobowiązkowe.
