Création d'un article => Gestion de l'utilisateur [Résolu]

[heretik25]

Bonjour,

Au sein de mon site perso, l'utilisateur peut créer un article, envoyer des images et finalement créer l'article... Comment pourrait-on gérer le cas où l'utilisateur upload des photos puis décide pour une raison ou une autre d'arrêter la publication de son article.

En effet, en uploadant les photos, un dossier se créer et si l'utilisateur quitte le navire, le dossier et ses photos resteront sur le serveur et seront inutiles.

Comment gérez vous ce cas de votre côté ?

Merci pour votre aide et retour d'expérience.

[armel18]

bonsoir,
je suppose que la table article est liée à la table image d'une part et la table image contient la clé étrangère article_id d'autre part.Dans un tel contexte quand l'utilisateur soumet le formulaire( ex de champs:nomArticle, contenuArticle, image1, image2...) alors:
-on insère les données dans la table article
-si insertion dans la table articlle===TRUE
alors
on récupère l'id de l'image inserée( $db->lastInsertId()
on fait appel à la méthode d'upload et on insère les données(nomImage,article_id..) dans la table image.

Une autre façon de le faire c'est d'utiliser les triggers SQL

[RunCodePhp]

Salut

En effet, en uploadant les photos, un dossier se créer et si l'utilisateur quitte le navire, le dossier et ses photos resteront sur le serveur et seront inutiles.

Donc les photos seraient déposées dans un dossier bien distinct.
Dans ce cas là il suffirait de supprimer toutes les photos de ce dossier y compris le dossier lorsque l'utilisateur quitte le navire.
Je ne vois pas où est la difficulté.

Qu'est-ce qui détermine de ton coté qu'un utilisateur quitte le navire ?
Il est peut être là ton problème ?

[ericd69]

salut,

je suis d'accord avec RunCodePhp, ton seul problème c'est de savoir si l'article est abandonné ou pas...

car savoir si un utilisateur a quitté le navire ça c'est presque impossible...

par contre un dossier images créer x semaines ou mois sans référencement dans la bd peut être considéré comme à supprimer...

[heretik25]

C'est bien ça le souci, comment déterminer si l'utilisateur quitte la navire ?

A part chercher si un article est accroché au dossier, je ne vois pas trop de solutions. Une autre idée ? Peut-on savoir si un user quitte le formulaire sans le valider ?

[ericd69]

ça dépend du formulaire mono ou multi-pages... déjà...

[heretik25]

Une page pour le formulaire, une autre pour le traiter.

[ericd69]

donc aucune image n'est envoyé tant que ton formulaire n'est pas validé!

[RunCodePhp]

Il n'y a pas de véritable solution à ce niveau à mon sens.

On peu cependant imaginer quelque chose en se basant un peu sur le fonctionnement des sessions, plus particulièrement comment sont supprimer les fichiers des sessions.
A savoir que ces fichiers de session sont supprimés par le garbage colector selon des probabilités et d'un délai d'expiration.

On pourrait donc créer une info (un flag, un booléen) : actif/inactif
Par défaut, donc lors de la création d'un article il serait d'office inactif.
Ce ne serait que lorsque l'article sera créé, donc dans un 2ème temps, où quelque part on obligera l'utilisateur à rendre actif son article.

Pour gérer alors ces articles inactifs (donc pour les utilisateurs qui quitterais le navire), il suffirait d'exploiter un cron qui se déclencherait périodiquement pour supprimer tous ces articles, y compris les photos et dossiers liés.
La période pourrait être 1 fois par jours, une fois par semaine, par mois, peu importe.

Pure suggestion.


Par ailleurs, et comme le dit Ericd69, si l'intégralité d'un article (des données) est traité d'un coup d'un seul formulaire, je ne vois vraiment pas où est le problème.

Par contre, si un article se fait par plusieurs étapes, plusieurs formulaires, les uns après les autres, qui donc pourrait déboucher sur des articles pas totalement finalisés, là ça cause effectivement problème.

A coté de ça, il faudrait peut être analyser l'ensemble des tes données sur ce point, et voir s'il n'y aurait pas quelque chose (ou un ensemble) où tu pourrais t'appuyer dessus pour détecter les articles non finalisés.
En somme, qu'est-ce qui définirait un article non finalisés.
Si tel est le cas, plus besoin de la suggestion que j'ai faite plus haut, suffirait juste de conserver la partie cron, c'est à dire de supprimer périodiquement les articles non finalisés.


C'est juste que quelques pistes, faut voir

[ericd69]

tu vois c'est ce que je te redis à chaque fois faut remettre tout à plat et repenser chaque situation finement...

[heretik25]

Envoyé par ericd69

donc aucune image n'est envoyé tant que ton formulaire n'est pas validé!

Si parce que les images sont envoyées par un système autonome de tinymce (le module payant de chez eux) tinymce image.

[heretik25]

Le dossier contenant mes images prends le nom de l'id de l'article. Pourrait-on créer une routine capable de scanner les différents dossiers, récupérer les id et supprimer les dossiers qui ne sont pas dans les différents id des articles existants.

[RunCodePhp]

Si parce que les images sont envoyées par un système autonome de tinymce (le module payant de chez eux) tinymce image.

Il aurait été pas mal de le dire dès le début non ?
De plus tu nous fait partir sur de fausse conclusion en disant qu'il y avait 1 formulaire 1 page pour la traiter.
Toujours pas l'ombre d'une allusion sur tinymce

Le dossier contenant mes images prends le nom de l'id de l'article. Pourrait-on créer une routine capable de scanner les différents dossiers, récupérer les id et supprimer les dossiers qui ne sont pas dans les différents id des articles existants.

Oui, pourquoi pas.
Regarde du coté de la fonction glob(), elle pourrait être utile.


Si je comprends bien (au passage, t'es assez avare en explication, faux sans cesse lire entre les lignes, supposer que ...), ce n'est pas l'article qui causerait problème, mais le fait qu'un utilisateur puisse uploader des photos sans pour autant avoir crée l'article en question.
En somme, tu te retrouverais avec des photos sous le bras à ne pas savoir qu'en faire.

Malgré tout, si tel est le cas il y a quelque chose qui me chiffonne.
Comment se fait-il que le nom du dossier contenant les images puisse contenir l'identifiant de l'article ???
Si l'article n'est pas créé il ne devrait pas être possible de créer ce dossier avec un identifiant qui n'existerait pas encore.
Si tel est le cas toujours, il y aurait à mon sens un problème de conception.
Ceci provoque justement une certaine corruption de ton application.

Dans certains CMS pour exemple, un article est créé automatiquement, quitte à mettre des valeurs par défauts, limite bidon (celles indispensables), et l'article est considéré au départ comme un brouillon.
Un brouillon ne sera jamais publié, ce qui obligera l’utilisateur de le rendre actif dans un second temps.
Donc d'une part on aura obligatoirement un identifiant de l'article. Plus de corruption possible.
D'autre part, si l'utilisateur n'en veut plus (quitte brutalement), il y aura alors moyen de supprimer les brouillons très facilement, y compris les photos qui seraient liées.
Bref ... c'est ni plus ni moins la suggestion que je t'avais faite (inactif ou brouillon c'est dans le même esprit).


Ne serait-il pas possible de décrire clairement ton problème afin de nous éviter de faire de multitudes de propositions/suggestions ou autres conclusions franchement hasardeuse ?
Je ne cesse d'en faire sans jamais un retour de ton coté d'une part, puis je ne sais toujours pas avec certitude ton réel problème.
A part supposer que

[heretik25]

Désolé si parfois je n'arrive pas à m'exprimer clairement sur les problèmes que je rencontre. 100 coups de fouet pour ce soir.

Après je ne pense pas que toutes les solutions/réflexions proposées soient inutiles. Cela me permet d'ouvrir d'autres perspectives. De plus, ma question d'origine était vague car je cherchais avant tout des concepts dont vous auriez eu vent ou me fournir la logique a adapter.

Aujourd'hui, l'outil n'est utilisé que par moi donc je fais attention à ne pas quitter le navire si j'ai ajouté des images. C'est une réflexion que j'ai à moyen termes.

Maintenant, le dossier prend l'id de l'article parce que je vais chercher le prochain id auto incrémental pour le renommer. Peut-être qu'il s'agit d'une mauvaise conception mais comment faire pour renommer le dossier avec l'id de l'article étant donné que l'utilisateur ajoute ses photos avant de valider le formulaire global ?

Faire un brouillon, pourquoi pas, il faut que je regarde si c'est envisageable.

Je clos le sujet.

@bientôt et encore merci pour le temps que vous me consacrez.

[RunCodePhp]

Maintenant, le dossier prend l'id de l'article parce que je vais chercher le prochain id auto incrémental pour le renommer. Peut-être qu'il s'agit d'une mauvaise conception mais comment faire pour renommer le dossier avec l'id de l'article étant donné que l'utilisateur ajoute ses photos avant de valider le formulaire global ?

A mon sens ce n'est pas une bonne approche de récupérer l'ID du prochain article, ça peu provoquer un bug.

Imaginons un instant le scénario suivant :
1/ Le User_A va créer créer un nouvel article. Donc dans un premier temps il upload une photo.
Le dossier va avoir (pour exemple) comme ID (le soit disant prochain article) : 100.
Ce User_A est quelque peu lent, ou dérangé temporairement au téléphone, donc ne valide pas encore le formulaire

2/ Le User_B va aussi créer un nouvel à ce même moment. Là aussi il upload une photo.
Le dossier va avoir comme ID : 100
Le User_B valide l'article avant le User_A -> Bug

Et oui, la logique voudrait que ça soit 101, mais non, c'est bel est bien 100 car l'article du U_ser_A n'a pas encore été validé, c'est à dire enregistré dans la Bdd, et du coup la valeur suivante reste la même, quelque soit le nombre de User qui va uploder des photos d'ailleurs tant qu'ils ne valident pas leur article.

Plus besoin de poursuivre ce scénario, plus ça va, moins ça va


C'est pour cela qu'il vaut mieux respecter l'idée qu'il y a derrière ce auto-increment.

L'auto-increment n'est pas juste quelque chose permettant d'avoir un ID créé automatiquement, c'est avant tout pour garantir l'unicité de chaque élément/enregistrement.
Vouloir renommer soit même une valeur auto-incrémentée n'est pas non plus une bonne idée.
Pourquoi ?
Pour la simple raison que, s'il y a des éléments liés avec cette valeur là, et qu'on a la mauvaise idée d'oublier de les supprimer (ça peu arriver si on exploite pas 100% le coté relationnel), et bien il y a de forte chance qu'un jour on va lier certains éléments accidentellement avec d'autres qui ne devraient pas l'être.

En faite, quand on exploite un champ auto-incrémenté, on laisse la Bdd gérer cette valeur là.
Si on supprime une de ces valeurs, MySQL ne réutilisera jamais cette même valeur, et c'est ça qui va réellement garantir cette unicité qui est recherché, et qui apporte de la fiabilité sur tous les éléments liés.

Ré-accorder soit même une valeur auto-incrémenté par MySQL, pourquoi pas, mais à condition de réellement connaitre tous les éventuels effets de bords qu'il peu avoir en faisant ça, sinon c'est franchement casse gueule.


Pour ma part, et dans ton cas, je ne vois de réel problème pour gérer ça.
Suffit de créer cet article juste avant l'étape d'upload (ou juste après si l'upload c'est bien effectué), en tout cas, pendant cette étape d'upload, quitte à mettre des valeurs par défaut.
Du coup, tu auras la valeur réelle et définitive de l'article, du coup la Bdd ne peu pas être corrompue, pas de bug possible à ce niveau.

A ce moment l'article sera considéré comme un brouillon (ou inactif, c'est pareil).
Suffit de le rendre actif (ou comme un véritable article) une fois que le User aura validé le formulaire.
Suffit pour ça d'un peu de JS ou Ajax pour intégrer l'ID de l'article dynamique dans le formulaire pour la finalisation.
Ou pourquoi pas exploiter les sessions.
Bref ... les solutions ne manquent pas.


Je te donne juste ma vision, c'est à toi de voir

[heretik25]

Merci, je vais regarder de ce côté là : créer un brouillon à l'upload des photos ou alors dès que l'utilisateur clic sur "créer l'article". Ajout de valeurs bidon et du coup, passer en mise à jour lors de l'envoi de l'article définitif.

Une routine pourra peut être par la suite supprimer les brouillons qui n'ont pas été validé sous x jours.

Encore merci :-)

[RunCodePhp]

ou alors dès que l'utilisateur clic sur "créer l'article"

Non, c'est ce que ne cesse de t'expliquer, ce que je ne conseil pas en tout cas.

Apparemment tu ne verrais toujours le gros problème en procédant ainsi.
Tout est une question de probabilité à la base.

Si on upload une photo avant de créer l'article, déjà on a ce 1er problème d'Identifiant : Quelle valeur lui accorder ???

Vient ensuite le 2ème problème en question : Quelle est le temps qu'il va avoir entre le moment où l'upload aura été fait et le moment où (le véritable) l'article sera créé.
Ici, c'est total inconnu, et ça va même jusqu'à ce qu'une personne ne cliquera sur "créer l'article".
Du coup, les probabilités où il y aurait 2 personnes créant un nouvel article quasi au même moment peuvent être fortes, ce temps de latence qu'il y a entre l'upload des photos et le clic sur "créer l'article" devient franchement problématique (Identifiants hasardeux).

Rien que ça normalement suffit pour dire qu'il y a un problème de conception.

En créant en 1er l'article, donc en obtenant définitivement et tout de suite un Identifiant unique règle d'office le(s) problème(s).
Après ça, qu'on fasse en sorte que ce sera un brouillon ou autre, ça n'a quelque part peu d'importance.
Le plus important c'est d'obtenir un Identifiant fiable à 100% (donc fiable quelque soit le cas de figure).

La routine de code pour supprimer ces fameux brouillons, ça aussi c'est pas le plus important, ça peu se gérer de plusieurs façons.

C'est simple, faut pas chercher compliqué.
C'est ton principe actuel qui est justement compliqué.

[heretik25]

Je pense qu'on s'est mal compris sur la fin quand je disais "créer l'article" je pensais "créer un article". Ce lien créerait en base un brouillon qui serait ou non validé par la suite par l'utilisateur lorsqu'il validerait le formulaire.

Des pistes sur le comment procéder pour remplir une bdd mysql au clic d'un lien ?

Merci.

[RunCodePhp]

Des pistes sur le comment procéder pour remplir une bdd mysql au clic d'un lien ?

Javacript / Ajax.

A un moment tu évoquais tinyMCE, et ce serait lui qui uploaderait les photos.
L'idéal serait de voir comment il est goupillé, qu'est-ce qu'il offre comme possibilité (ou liberté), et ça sans devoir éplucher tout le code, pour réaliser l'enregistrement de l'article quasi au même moment de l'upload de la photo.
Ceci devrait se faire en Ajax.
Toujours est-il que l'utilisateur fera obligatoire un click pour valider l'upload de la photo, ceci va obligatoirement exécuter quelque chose.
On peu donc obligatoirement faire quelque chose à cet instant, le tout c'est de savoir où ça se passe dans le code de tinyMCE, et de pouvoir l'exploiter.

Personnellement je ne connais pas tinyMCE (sauf de nom), je ne peux pas t'aider la dessus.