Re: [Dotclear Dev] [Dotclear Forum] Signalement (11) - « Réécriture d'URL chez OVH et erreurs 404 (PHP_VER 5_4) »
by Jean-Christian Denis
J'avais déjà donné une solution il le semble sur le forum il y a un baille... pas le temps de répondre mieux je suis sur une pelleteuse !
Dsls <dsls(a)morefnu.org> a écrit :
>Le 7 août 2012 13:37, Dsls <dsls(a)morefnu.org> a écrit :
>> Le 7 août 2012 11:37, Forum Dotclear - Dotclear 2 E-mail automatique
>> <webmaster(a)dotclear.net> a écrit :
>>> L'utilisateur « amalgame » a signalé le message suivant : http://forum.dotclear.org/viewtopic.php?pid=315313#p315313
>>> Motif : Le problème persiste en PHP 5.3 ou 5.4 chez OVH. Chez moi, la page d'accueil renvoie un code 404 mais s'affiche néanmoins correctement, les autres pages renvoient 200 OK... Une idée, Dsls ?
>>
>> Marrant, j'avais relevé ce problème il y a 2 ans, lors de mes tests
>> php 5.3. Il semblerait que ce soit le triplet PHP 5.3 / Rewrite Rules
>> / PATH_INFO qui en soit à l'origine...
>>
>> Cela dit, je n'ai pas la moindre idée de piste sur le sujet...
>
>En fait si, j'ai tweeté la cause du problème le 15/06/2010 :
><<
>Trouvé. Les RewriteRules chez OVH ne marchent pas vers des URLs en
>PATH_INFO si on est en PHP 5.3.2, alors qu'en 5.2 ça marche nickel...
>>>
>
>Ça date :)
>_______________________________________________
>Dev mailing list
>Dev(a)list.dotclear.org
>http://ml.dotclear.org/listinfo/dev
11 years, 8 months
[Sexy] Evolutions JS
by Dsls
Hello,
Un des chantiers envisagés il y a quelques temps était la remise à
plat de tout la partie JS. Je propose de s'y mettre sur la branche
sexy.
Dans le périmètre :
* Passage à la dernière version de jquery (v1.7.2)
* Remplacement des devs maison (tabs, colorpicker, datepicker ...) par
jQuery-Accessible-RIA
(https://github.com/fnagel/jQuery-Accessible-RIA)
--
Bruno
11 years, 9 months
Idées sur le nouveau gestionnaire de médias
by Dsls
Re,
Maintenant que la branche sexy n'a plus de gestionnaire de médias, je
remets sur le tapis le sujet de refonte du gestionnaire de médias, qui
reviendra sous forme d'un plugin.
Les limitations de l'ancien gestionnaire de médias :
* peu d'extensibilité
* pas ouvert vers les médias externes
* limité à 1 media_path par blog.
Le nouveau modèle proposé :
* Ajout d'un "media provider" (ex typique : un couple media_path/media_url,
mais extensible à d'autres types de fournisseurs : youtube, flickr, ...)
* Les médias sont tous associés à un media provider
* Ajout d'une table dc_media_meta pour mieux gérer les métadonnées des
médias
* Ajout d'urlhandlers dédiés aux médias
* Nouveaux templates tpl:Media
Plutôt que de continuer à paraphraser une vieille page sur le sujet,
ci-dessous un copier-coller de la réflexion :
Refonte du gestionnaire de médias
Le but de cette page est de dégrossir la prochaine cible du gestionnaire de
médias
Classes core dcMedia
- rendre cette classe indépendante du provider de médias.
- fournir des méthodes type getPosts de dcCore
- permettre d'étendre chaque recordset via le media provider associé
dcMediaProviders
Classe abstraite, à étendre en dcMediaLocal, dcMediaYoutube, dcMediaFlickr
- Permet d'avoir les informations sur un média donné (URL, miniature,
inventaire, ...)
- Permet de synchroniser les médias (nouveaux, supprimés, ...)
Coté public
- URLHandlers : proposer un URLHandler pour afficher un média (le plugin
dlManager a déjà défini des
URLs<http://lab.dotclear.org/browser/plugins/dlManager/trunk/_prepend.php>et
des
fichiers template<http://lab.dotclear.org/browser/plugins/dlManager/trunk/default-templates>--
Moe)
- proposer les templates liés à ce urlhandler
- nouveaux templates : <tpl:Media></tpl:Media> ...
Coté admin
- Proposer une vision sous forme de liste, pas forcément dépendante du
répertoire. Un répertoire devient un filtre comme un autre
- Points d'extension coté liste de médias, sélection multiple, actions
groupées (déplacement, suppression, regénération, ...)
- Points d'extension coté affichage média (rotation, redéfinition
miniatures, manipulation métadonnées, ...)
Tables dc_media
Objectif : limiter les impacts sur la modification de cette table Structure
actuelle :
- media_id (bigint) : id du média
- user_id (varchar 32) : utilisateur
- media_path (varchar 255) : chemin du répertoire public
- media_title (varchar 255) : titre du média
- media_file (varchar 255) : nom du fichier contenant le média
(répertoire inclus)
- media_dir (varchar 255) : répertoire contenant le média
- media_meta (text) : métadonnées de l'image (structure xml)
- media_dt, media_creadt, media_upddt
- media_private (smallint)
Evolutions à porter :
- Remplacer media_path par mp_id, avec jointure avec dc_media_pro (le
media_path est alors porté par la table dc_media_pro)
dc_media_pro
Nouvelle table, elle décrit les fournisseurs de médias :
Champs :
- mp_id (bigint) : identifiant du provider
- mp_type (varchar 64): type du provider ("file", "youtube", "flickr")
- mp_name (varchar 255) : nom du provider ("Compte youtube de toto")
- ... (à compléter selon étude)
dc_blog_media_pro
Nouvelle table, elle associe des media providers à un blog :
Champs :
- blog_id () : identifiant du blog
- mp_id (bigint) : identifiant du media provider
dc_media_meta
L'idée de cette table est de calquer les mécanismes de dc_meta, mais pour
les médias. En plus d'avoir des métadonnées des médias dans un champ de dc_
media, elles sont en plus stockées en table. Cela permet un requêtage plus
complet sur les médias. Structure proposée : comme dc_meta, à savoir :
- media_id( bigint) : id du média
- meta_value (varchar 255) : contenu de la métadonnée
- meta_type (varchar 64) : nom de la métadonnée
dc_post_media
Cette table a un rôle très limité actuellement, elle sert uniquement à la
gestion des pièces jointes.
Elle prendrait un sens beaucoup plus complet si ont pouvait qualifier le
type de lien post <-> média Nouvelle structure :
- post_id (bigint) : id du billet
- media_id (bigint) : id du média
- link_type (varchar 64) : type de lien entre billet et média
Exemples de link_type : "attach" pour une pièce jointe (valeur par défaut
pour rétrocompatibilité), "embed" pour un média inclus dans un billet (par
exemple pour propager un renommage d'un média au sein d'un billet, gérer
les effets de bord à ma suppression d'un média)
11 years, 9 months
Re: [Dotclear Dev] Admin version mobile
by Thomas Daveluy
Sur android on peut le faire sur la plupart des téléphones, donc
effectivement c'est pas un problème (le système de mise en forme du texte
est un peu délicat a utiliser avec un smartphone en revanche)
Après moi je suis un peu réticent avec les interfaces mobiles, la plupart
des nouveaux smartphones gérant très bien l'affichage, le passage en
interface mobile devient plus une gène qu'autre chose.
Z'en pensez quoi?
Le 6 août 2012 12:31, "Patrick Olivier" <patidou(a)gmail.com> a écrit :
11 years, 9 months
Admin version mobile
by Patrick Olivier
Salut,
C'est un gros morceau mais est-ce prévu que l'admin s'affiche en version mobile?
Je parle ici d'ajout de media queries dans les css pour ne pas tout refaire (et éventuellement de jquery ui mobile sur la branche sexy).
Merci d'avance.
P.S. : Pas taper. :-)
--
Patidou
11 years, 9 months
EntryFirstImage
by Denis Jean-Christian
Quelqu'un travail sur EntryFirstImage, j'ai vu qu'il y a un paquet de
tickets sur cette fonction ?
Cordialement,
JC|à donf
11 years, 9 months
Ticket #1200 POST vs GET
by Denis Jean-Christian
Bonsoir à tous,
Je suis en train de faire le ticket #1200 (
http://dev.dotclear.org/2.0/ticket/1200 ) qui consiste a réécrire et
regrouper plus proprement différents fichiers admin (users.php,
dispatcher.php, permissions.php, permissions_blog.php) qui jouent avec
les permissions utilisateurs et je suis tombé sur un os.
On m'a toujours appris à faire mes formulaires en POST lorsque c'est
pour des modifs en base hors ici ce n'est pas le cas, les ids des
utilisateurs sont passés en GET pour la suppressions d'utilisateurs et
également sur les filtres du choix des blog pour les permissions.
Je ne sais pas si c'est grave et le passage en POST est à priori
possible sauf sur les filtres/pager du choix des blogs pour lesquels je
n'ai aucune solution. Quelqu'un à une idée, un avis ?
PS: En passant, ces fichiers sont bourrés d'erreurs de typo.
PS2: Désolé si j'utilise cette mailing-list comme un forum.
JC
11 years, 9 months
Gestion des mises à jour.
by Dsls
Hello,
J'ai quelques remarques concernant le mécanisme de mises à jour du
core et des plugins/thèmes.
Actuellement :
* Quand on met à jour le core, on déroule le
téléchargement/remplacement de la nouvelle archive, puis on invite
l'utilisateur à se reconnecter. Lors de la reconnexion, c'est
admin/index.php qui finit la mise à jour via un timide message
d'information en haut.
* Quand on met à jour un plugin/thème, même topo, mais lorsque
l'install du plugin/thème est faite, on est dans le contexte du blog
courant de l'utilisateur qui se connecte.
Les problèmes actuels:
* Tant que l'utilisateur ne s'est pas reconnecté pour finaliser
l'installation, toute la ferme est dans un état instable
* On espère que la mise à jour lors de la connexion ne prend pas trop
de temps pour que tout soit fait en une seule page PHP
* On espère que l'utilisateur qui se connectera juste après la màj
sera un super administrateur
* Au moment du clic sur le fameux "vous êtes à 1 clic de la fin", seul
le super administrateur est déconnecté
Je propose le nouveau comportement suivant :
* Le clic sur le "vous êtes à 1 clic de la fin" déconnecte TOUS les
utilisateurs de la ferme
* tant qu'un super-admin ne s'est pas reconnecté :
* Tous les blogs sont placés "en maintenance", avec page d'accueil spécifique
* Aucun autre utilisateur ne peut se connecter
* On met en place une page dédiée "post-installation" à la place de la
notification timide, qui permet éventuellement d'être multi-étapes,
voire asynchrone, pour permettre de gros upgrades. Seul le passage de
toutes les pages de mise à jour réactive l'accès aux autres
utilisateurs à l'admin
--
Bruno
11 years, 9 months
