YesWiki is a wiki system written in PHP, including extensions making collaboration more simple (databases, maps, easy editing, bootstrap themes,...).

Overview

YesWiki

YesWiki is a Free Software under the AGPL licence, made for creating and managing your website, in a collaborative way.

YesWiki allows any web user, online, with any browser, to :

  • create, delete, edit or comment on the pages of a site, with any number of editors or pages.
  • manage access rights for each page (read, write, or comment) for a user or a group.
  • layout a page content in a very intuitive and visual way, using formatting rules which require no technical skills.
  • publish immediately any creation or modification of a page.
  • analyze and manage the whole site through simple functions : site map, list of users, most recently modified or commented pages, etc.
  • a set of templates to suit any site need in term of presentation
  • ability for each part of a site to act as Wiki page : title, header, menus, footer etc. can be easily edited from a browser.
  • a light but strong anti-spam solution.
  • the possibility to embed documents in a page : pictures, mp3, videos, mind maps etc.
  • a plugin manager and numerous extensions : user oriented database manager, tags, contact forms, etc.

Installation

YesWiki can be installed in about ten minutes on a server which supports PHP >= 7.3 and a MySQL >= 5.6 database. Once installed, the YesWiki site is working immediately, and can be managed online from a web browser.

More detailled install instructions in the INSTALL.md file.

History

YesWiki grew out of a French language version of WakkaWiki called Wikini, and hence has strong French language support.

Authors and contributors

Initial WakkaWiki author

Wikini authors

  • 2003 Carlo ZOTTMANN
  • 2002, 2003, 2004 David DELON
  • 2002, 2003, 2004 Charles NEPOTE
  • 2002, 2003, 2004 Patrick PAUL
  • 2003 Eric DELORD
  • 2003, 2004 Eric FELDSTEIN
  • 2003 Jean-Pascal MILCENT
  • 2003 Jéréme DESQUILBET
  • 2003 Erus UMBRAE
  • 2004 David VANTYGHEM
  • 2004 Jean Christophe ANDRE

YesWiki authors

See https://github.com/YesWiki/yeswiki/graphs/contributors

Comments
  • Docsify

    Docsify

    Amélioration de la documentation embarquée

    Cf cette ébauche de Readme : https://md.yeswiki.net/e9kPN6HHQUyrxKXC46OLHg?both#

    • Url dédiée ?doc
    • Début de restructuration des fichiers
    • Téléchargement des images depuis la doc en ligne
    • Amélioration de la visibilité du menu
    • Suppression des langues autre que français
    • Affichage de la doc avec la langue du wiki. Suppression du sélecteur de langue
    • Affichage de code yeswiki executé via une iframe

    Comment tester

    [[En allant sur ?doc](En allant sur ?doc)](http://localhost:81/?doc)

    opened by seballot 48
  • Aceditor refactor & features Fixs #1023

    Aceditor refactor & features Fixs #1023

    Yo !

    voilà je pense que la PR est prête pour review. Niveau code, il y a beaucoup de commits et changements, donc le ieux est peut être plutot de regarder l'état final : AceditAction.php aceditor.js etc..

    Il y aura aussi besoin d'un bonne série de tests ! Candidate potentielle pour la release 4.4

    Voilà le contenu

    Amélioration de la création de page

    Modal de création/édition de lien simplifiée

    image

    Nouveau bouton pour créer une page

    image

    image

    Petit crayon pour éditer les liens

    image

    Ancienne syntaxe de lien de nouveau par default

    Lorsque je crée un lien depuis image si le lien s'ouvre dans l'onglet courant alors il utilise la syntaxe classique [[Lien texte]] puisqu'il y a maintenant le lien pour l'éditer

    Autocompletion pour les lien et les actions

    Peek 08-10-2022 20-01

    Plusieurs aceditor par page

    Les composants marchent maintenant dans chaque editeur

    Refactor Aceditor

    J'ai regroupé et converti pas mal de bout de code qui étaient éparpillées et qui fonctionnait indépendamment, rendant assez dur à suivre le fonctionnement de aceditor

    Maintenant il y une action AceditorAction (qui s'invoque depuis un twig avec le nouveau helper renderAction)

    {{ renderAction('aceditor', { saveButton: true, name: 'body', value: body })|raw }}
    

    Cependant, du au fait que l'on ne peut pas mettre un élément HTML form dans un autre, il faut aussi ne pas oublier d'inclure les différentes modals via un {{ include('@aceditor/aceditor-modals.twig') }}

    Ensuite la classe javascript Aceditor va s'initialiser pour chaque éditeur de la page, gérer la toolbar, gérer les aide à la saisie de l'éditeur (autocompletion, petit crayon pour éditer les actions et les liens), et initialiser les différentes modals (actions-builder, files, link...)

    Refactor handler edit

    Pareil y'avait plusieurs bout de code éparpillé, du à l'utilisation des callback edit__.php. J'en ai regroupé certains, mais pas tous. Il y aura encore les actions relatives aux tags et au selecteur de thème à refactorer pour les inclure directement dans handlers/edit.twig

    opened by seballot 34
  • Proposition de gestion des releases

    Proposition de gestion des releases

    Voilà là proposition qu'on fait avec florian :

    On garde le système actuel de build de version (https://github.com/YesWiki/yeswiki-build-repo + https://github.com/YesWiki/yeswiki-config-repo/blob/master/repo.config.json)

    On utiliserait maintenant 2 versions (en plus de cercopitheque)

    • une version "stable" qui se base sur des tags publiés de manière ponctuelle, genre "4.1.12". c'est la version utilisée par default i.e. {{ update }}
    • une version "dev/test" qui se base sur le dernier commit de la branche doryphore. Réservée aux utilisateurs avancés qui configureront leur wiki avec {{ update version="nom_de_cette_version_test" }}

    Pour le nom de ces deux versions, soit on continue un naming aligné sur les version majeure (perso je pense que c'est le plus simple) version stable: "doryphore" version test: "doryphore-test" puis on aura pareil avec ectoplasme

    Soit on prend un nom generique et on assure le passage d'une version majeure à une autre version stable : "stable" version test: "test"

    Pour les commits :

    • Création d'une nouvelle branche doryphore-dev (ou peut être tout simplement dev): tous les commits arriveront désormais sur cette branche, via PR ou en direct
    • Quand on juge que y'a assez de nouvelles features pour une release, on fast forward doryphore vers doryphore-dev (ou on merge si on peut pas fast forward). La future release sera en phase de test, accessible via {{ update version="doryphore-test" }}
    • Si des bugs sont trouvés, un commit de fix est poussé sur doryphore-dev, puis copié sur doryphore (git cherry pick)
    • Si de nouveaux devs sont fait entre temps, ils sont poussés sur doryphore-dev, mais ne seront pas mergés dans doryphore (on est en feature freeze)
    • Quand on a assez joué avec la version "test" et que y'a plus de bugs (ici on peut prendre vraiment le temps de tester, genre 1 mois, d'ou l’intérêt d'avoir la branche doryphore-dev pour continuer à faire d'autres devs), on créé un nouveau tag sur doryphore en incrémentant la version. Tous les utilisateurs auront donc accès à la nouvelle version via ce tag

    Intégration continue

    Si on se chauffe, y'a l'idée de déclencher le build des versions dès que y'a un push sur doryphore ou un nouveau tag créé. On pourrait même mettre à jour automatiquement testing.yeswiki.net avec la version test dès que y'en a une publiée

    Voilà pour les grandes, lignes, ça vous botte?

    concertation 
    opened by seballot 34
  • Improve merge fields entry (!!! + BazarField RetroCompField refacto !!!)

    Improve merge fields entry (!!! + BazarField RetroCompField refacto !!!)

    11 mars 2021:mise à jour de cet en-tête Intention principale : pouvoir éviter que les anciens champs restent présents dans une fiche.

    • modification de EntryManager pour la méthode de fusion des données lors de l'update (ne pas ajouter les anciennes données mais que celles qui correspondent à un champ).
    • mise à jour de quelques Fields pour rester compatibles avec canEdit
    • refacto pour la gestion des anciens champs sous forme de fonction (parce que ça devenait trop compliqué de maintenir la rétrocompatibilité comme le code était, maintenant c'est plus simple).
    • refacto du Guard pour prendre en compte directement les BazarField
    • corrections de quelques erreurs dans le EntryManager

    Tests du 11 mars 2021 Tests #670.zip

    Cette PR semble intégrer des modifications qui ne sont pas prioritaires. Toutefois, elle permet de résoudre le problème de données en trop (BUG) et aussi facilite la correction des autres futurs bugs. C'est pour ceci que je me permets de le proposer sur Doryphore et non Ectoplasme


    Texte d'avant

    Lors de la mise à jour d'une fiche, il y a pour le moment fusion entre les anciennes données et les nouvelles données. Conséquence:

    • ça permet de reconstruire les données manquantes qui auraient pu disparaître lors du passage sur le navigateur du client.
    • ça complique la remise à zéro des données en tableau comme les checkbox
    • ça ne permet pas de supprimer les anciennes données qui ne sont plus utilisées.

    Le correctif que je propose permet de continuer de récupérer les anciennes données sans garder les données qui sont maintenant inutiles.

    Je te sollicite @acheype dans un premier temps pour avoir ton avis. Qu'en penses-tu ? J'ai ouvert une PR pour permettre un espace d'échange facilité. Elle est en brouillon car elle n'est pas prête à être fusionnée. N'importe qui peut se joindre à cette discussion voire faire une revue. :wink:

    J'ai des questions sur la possibilité de déplacer la sauvegarde des données des champs non accessibles en écriture dans les champs dédiés.

    ET je n'ai pas encore fait tous les tests

    proposition prêt 
    opened by J9rem 33
  • Feat/archive

    Feat/archive

    Cette PR permet d'introduire une fonctionnalité d'archivage asynchrone du wiki. Spécifications pour cette PR : https://pad.lescommuns.org/YmnJJPjJRMGj7EhAlD1eZg#

    Pour tester:

    • faire /update une fois sur la branche feat/archive
    • penser à faire un composer install juste au cas où
    • se rendre sur la page GererMisesAJour :
      • il y a alors un bouton "Gérer les sauvegardes"
      • une sauvegarde est lancée avant chaque mise à jour

    Matrice de couverture de la spécification: |Numéro|Nom|Implémenté|Testé|Commentaire| |:-|:-|:-|:-|:-| |[R01]|console + command spécifique|[x]|[x]|| |[R02]|command avec params|[x]|[x]|| |[R02.1]|params pour choix sql, fichiers ou tout|[x]|[x]|| |[R02.2]|par défaut tout|[x]|[x]|test par lecture du code| |[R02.3]|nom des fichiers|[x]|N.A.|voir constantes dans ArchiveService| |[R02.4]|params extrafiles|[x]|[x]|test manuel| |[R02.4.1]|params extrafiles chemins relatifs|[x]|[x]|test phpunit| |[R02.4.2]|params extrafiles OK pour dossiers|[x]|[x]|test manuel| |[R02.4.3]|params extrafiles OK pour sous-dossiers|[x]|[x]|test manuel| |[R02.4.4]|params extrafiles compatible glob|[x]|[x]|test manuel| |[R02.4.5]|params extrafiles save dans wakka.config.php du zip|[x]|[x]|test phpunit| |[R02.4.6]|params extrafiles configurable via frontend|[x]|[x]|tests manuels| |[R02.4.8]|params extrafiles save dans wakka.config.php du zip sous forme de tableau|[x]|[x]|test phpunit| |[R02.4.9]|params extrafiles ne doit tenir compte que des chemins inclus dans le dossier de tête|[x]|[x]|test phpunit| |[R02.5]|params excludedfiles|[x]|[x]|test hors phpunit| |[R02.5.1]|params excludedfiles chemins relatifs|[x]|[x]|test phpunit| |[R02.5.2]|params excludedfiles OK pour dossiers|[x]|[x]|test phpunit| |[R02.5.3]|params excludedfiles compatible glob|[x]|[x]|test hors phpunit| |[R02.5.4]|params excludedfiles save dans wakka.config.php du zip|[x]|[x]|test phpunit| |[R02.5.5]|params excludedfiles configurable via frontend|[x]|[x]|tests manuels| |[R02.5.6]|params excludedfiles save dans wakka.config.php du zip sous forme de tableau|[x]|[x]|test phpunit| |[R03]|permettre l'anonymisation de wakka.config.php|[x]|[x]|test phpunit| |[R03.1]|anonymisation de wakka.config.php réglable par un paramètre|[x]|[x]|test phpunit| |[R03.2]|anonymisation de wakka.config.php valeurs par défaut|[x]|[x]|test phpunit| |[R03.3]|anonymisation de wakka.config.php save dans wakka.config.php|[x]|[x]|| |[R03.4]|anonymisation wakka.config.php avec tableaux aussi|[x]|[x]|test phpunit| |[R03.5]|anonymisation wakka.config.php avec tableaux : format|[x]|[x]|test phpunit| |[R04]|un controlleur pour appeler la CLI|[x]|[x]|test phpunit| |[R04.1]|un controlleur dans includes|[x]|[x]|test par lecture du code; c'est un service| |[R04.2]|le controlleur fournit les paramètres d'anonymisation|[x]|[x]|test phpunit| |[R04.3]|les paramètres d'anonymisation ne peuvent être réglés par le frontend|[x]|N.A.|vérifiaction en lisant le code| |[R05]|la CLI vérifie le dossier n'est pas sur le web|[x]|[x]|tests manuel en suppriment .htaccess| |[R05.1]|chemin de sauvegarde dans wakka.config.php|[x]|[x]|test manuel| |[R05.2]|chemin de sauvegarde configurable via {{editconfig}}|[x]|[x]|test manuel| |[R06]|mode hibernate pendant la sauvegarde|[x]|[x]|proposition de créer un mode archiving| |[R07]|archivage sur PID différent|[x]|[x]|test phpunit + test manuels| |[R07.1]|utilisation possible de symfony/process|[x]|[x]|| |[R07.2]|pouvoir arrêter la CLI|[x]|[x]|test manuel| |[R07.3]|fournit un état instantané de la CLI|[x]|[x]|test manuel| |[R07.4]|communication avec la CLI via un fichier|[x]|[x]|test manuel| |[R08]|zip avec arborescence similaire au yeswiki|[x]|[x]|test phpunit| |[R08.1]|sauvegarde sql dans zip|[x]|[x]|test phpunit| |[R08.4]|sauvegarde sql dans zip private/backups|[x]|[x]|test phpunit| |[R08.5]|private/backups avec .htaccess et README|[x]|[x]|test phpunit| |[R08.6]|pas d'assurance de la sécurité des données|[x]|N.A.|| |[R09]|téléchargement du fichier sans lien direct|[x]|[x]|test manuel| |[R10]|pas de sauvegarde pendant une autre sauvegarde|[x]|[x]|test phpunit| |[R11]|vérification de l'espace disque avant de lancer une sauvegarde|[x]|[x]|test manuel| |[R11.1]|règle pour la marge d'espace disque|[x]|[x]|choix taille files + custom + 300 Mo| |[R12]|limiter le nombre de sauvegardes à 10|[x]|[x]|test manuel| |[R12.1]|toujours supprimer la plus ancienne|[x]|[x]|test manuel ! conserve toujours au moins une archive qui a deux jours| |[R12.2]|demander une confirmation du frontend avant suppression|[x]|[x]|test manuel| |[R21]|frontend via {{adminbackups}}|[x]|[x]|test manuel| |[R21.1]|pas d'impact dans {{update}}|[x]|N.A.|| |[R22]|{{adminbackups}} gestion des sauvegardes précédentes|[x]|[x]|test manuel| |[R22.1]|{{adminbackups}} actions : liste/télécharger/supprimer|[x]|[x]|test manuel| |[R22.2]|{{adminbackups}} actions : laisser la possibilité pour "restaurer"|[x]|N.A.|le code frontend contient déja des bouts de codes en commentaires| |[R23]|{{update}} lancer une sauvegarde automatique avant update|[x]|[x]|tests manuels| |[R23.1]|{{update}} sauvegarde auto contournable|[x]|[x]|tests manuels| |[R23.2]|{{update}} sauvegarde auto contourné = confirmation requise|[x]|[x]|tests manuels| |[R23.3]|{{adminbackups}} permet une sauvegarde manuelle|[x]|[x]|tests manuels| |[R23.4]|{{adminbackups}} permet la configuration de la sauvegarde|[x]|[x]|tests manuels| |[R23.5]|{{update}} sauvegarde auto contournable uniquement si param dans wakka.config|[x]|[x]|tests manuels| |[R24]|{{adminbackups}} VueJS possible|[x]|[x]|usage de VueJs avec syntaxe compatible vuejs 2 et 3| |[R25]|{{adminbackups}} appel routes API|[x]|[x]|| |[R25.1]|{{adminbackups}} appel routes API en ajax|[x]|[x]|| |[R25.2]|{{adminbackups}} suivi CLI en dynamique|[x]|[x]|test manuel| |[R25.3]|{{adminbackups}} permettre arrêter la CLI|[x]|[x]|test manuel| |[R25.4]|{{adminbackups}} rafraichissement mini 5 sec|[x]|[x]|test manuel| |[R26]|route API pour lancer la sauvegarde|[x]|[x]|test manuel| |[R26.1]|route API pour lancer la sauvegarde sauf si pas assez d'espace|[x]|[x]|test manuel| |[R26.2]|route API pour lancer la sauvegarde suppression auto de la plus ancienne si > 10|[x]|[x]|test manuel| |[R26.3]|route API pour lancer la sauvegarde limite 2 par jours maxi|N.A.|N.A.|non réalisable car c'est la même route api|

    N.A. : non applicable

    opened by J9rem 28
  • Groups links facette

    Groups links facette

    Je travaille en ce moment à réutiliser les facettes pour qu'elles puissent effectuer des filtrages au niveau de la vue ProgressDashboard du LMS. Je propose ces deux commit pour rendre plus clair le code.

    opened by acheype 27
  • Feat/newtextsearch2

    Feat/newtextsearch2

    Cette pull-request a pour objectif d'améliorer le fonctionnement de l'action {{newtextsearch}} en s'inspirant de ce qui a été fait sur un wiki existant de Villeurbanne

    Ceci est d'abord une pull-request draft, qui propose les améliorations en se basant sur des développements custom. Ne pas prendre le code proposé comme valide pour fusion tant que les spécifications ne sont pas validées. le code est d'abord proposé comme base de travail des spécifications qui peuvent invalider tout ou partie des modifications courantes.

    Proposition de spécifications:

    Spécification pour amélioration de l'action {{newtextsearch}}

    • [R01] : l'action {{newtextsearch}} DOIT être réécrite dans le nouveau format dans le fichier NewTextSearchAction.php
    • [R02] : le fichier docs/actions/advanced-actions.yaml DOIT être à jour par rapport aux modifications apportées concernant {{newtextsearch}}
    • [R03] : l'action {{newtextsearch}} DOIT maintenant proposé un template twig par défaut newtextsearch.twig qui affiche les résultats comme avant
    • [R04] : un nouveau template newtextsearch-by-form.twig devrait aussi être créé
    • [R04.1] : le nouveau template de [R04] DOIT permettre l'affichage des résultats classés par formulaires ou types de données
    • [R04.2] : le nouveau template de [R04] DEVRAIT afficher les données en colonnes.
    • [R04.2] : le nouveau template de [R04] DEVRAIT utiliser le nouveau paramètre nbcols pour déterminer le nombre de colonnes
    • [R04.3] : le nombre de colonnes du nouveau template de [R04] DOIT être entre 1 et 3
    • [R04.4] : si le parmaètre nbcols vaut 0 pour le nouveau template de [R04], alors la mise en colonne DEVRAIT se faire automatiquement en fonction de la largeur du contenu
    • [R04.5] : le nouveau template de [R04] DEVRAIT affiché les résultats classés par catégories
    • [R04.6] : le nouveau template de [R04] NE DOIT PAS être le template par défaut
    • [R04.7] : le nouveau template de [R04] DEVRAIT créer autant de lignes que nécessaire pour respecter le nombre de colonnes demandées
    • [R04.8] : le nouveau template de [R04] PEUT être un affichage dynamique
    • [R05] : le paramètre displaytype DEVRAIT être utilisé par les deux templates pour déterminer le type d'affichage selon:
      • modal : fenêtre modale
      • link : fenêtre courante
      • newtab : nouvel onglet
    • [R05.1] : la valeur par défaut de displaytype DEVRAIT être modal
    • [R06] : le paramètre displaytext DEVRAIT être utilisé uniquement par le deux templates pour déterminer s'il faut afficher le texte des résultats
    • [R06.1] : les valeurs de displaytext PEUVENT être:
      • true pour forcer l'affichage du texte
      • false pour ne pas afficher le texte
      • "" pour n'afficher le texte que pour le template par défaut (c'est la valeur par défaut)
    • [R06.2] : displaytext NE DEVRAIT être configurable qu'avec les paramètres avancés de composants
    • [R07] : le paramètre displaytypes DEVRAIT être utilisé par le nouveau template de [R04] pour déterminer ce qu'il faut afficher et dans quel ordre
    • [R07.1] : si le paramètre displaytypes est vide, le nouveau template de [R04] DEVRAIT afficher les résultats classés par formulaire pour les fiches, par ordre croissant de nom de formulaire suivi d'un bloc avec les pages sans les pages de logs
    • [R07.2] : le paramètre displaytypes PEUT accepter les syntaxes suivantes, séparées par des virgules
      • un nombre : pour un formulaire spécifiques
      • page ou pages : pour les pages sans les pages de logs
      • logpage, logpages, logspage, logspages : pour les pages de logs
      • tag:<nom-du-tag> (ex: tag:catégorie: 1 pour le tag catégorie: 1)
    • [R07.3] : si un résultat appartient à la fois à un tag et à la fois à un bloc page, logpage ou formId (un formulaire), ce résultat PEUT être afficher en doublon dans les deux catégories
    • [R07.4] : le paramètre displaytypes DEVRAIT pouvoir être saisi facilement depuis les composants (en développant un Input dédié si nécessaire)
    • [R08] : le paramètre titles DEVRAIT être utilisé par le nouveau template de [R04] pour déterminer le titre de chaque bloc
    • [R08.1] : la syntaxe du paramètre titles DEVRAIT être une concaténation de texte, chaque titre étant séparés par des virgules, classés dans le même ordre que le paramètre displaytypes
    • [R08.2] : si un titre est vide (ex: 1.Titre non vide 1,,3.Titre non vide 2), celui-ci DEVRAIT être remplacé par :
      • le label du formulaire pour les formulaires
      • Pages pour les pages (+ traductions)
      • Log pages pour les pages de logs (+ traductions)
      • Nom du tag pour les tags
    • [R09] : le paramètre limit DEVRAIT être utilisé par le template d'origine pour limiter le nombre total de résultats fournis
    • [R09.3] : le paramètre limit DEVRAIT avoir pour valeur par défaut 10
    • [R09.4] : le paramètre limit DEVRAIT automatiquement être remplacer par sa valeur par défaut si sa valeur initiale est inférieure ou égal à 0
    • [R09.6] : le paramètre limit DEVRAIT automatiquement être remplacer par sa valeur par défaut si sa valeur initiale est inférieure strictement à 0
    • [R09.7] : le paramètre limit DEVRAIT uniquement être utilisé par le nouveau template de [R04] pour déterminer le nombre maximum de résultats par catérgorie
    • [R10] : le nouveau template de [R04] DEVRAIT proposer un bouton voir plus quand la limite est atteinte par limit
    • [R10.2] : le bouton voir plus NE DEVRAIT PAS recharger la page pour n'afficher que les résultats de la catégorie concernée sans limite
    • [R10.3] : le bouton voir plus DEVRAIT mettre à jour la liste des résultats concernant la catégorie de façon dynamique
    • [R11] : le clic sur un résultat PEUT ouvrir la page avec une ancre au bon endroit
    • [R11.3] : les actions show__ et iframe__ DEVRAIT prendre en compte $_GET['searchAnchor'] afin d'ajouter à la volée une ancre pour faciliter la navigation

    Changements

    • 2022-08-31 [JD]:
      • [R04.6] ~~DEVRAIT~~ => NE DOIT PAS
      • [R04.7][R04.8] ajout
      • [R09] ~~tous les templates~~ => le template d'origine
      • [R09.1] suppression : ~~le paramètre nbbytypes DEVRAIT uniquement être utilisé par le nouveau template de [R04] pour déterminer le nombre maximum de résultats par catérgorie~~
    • [R09.2] suppression : ~~le paramètre limit DEVRAIT être prioritaire sur le paramètre nbbytypes~~
    • [R09.3] ajout de par défaut 100 pour le template d'origine est 10 pour le nouveau template
    • [R09.5] suprresionn ~~: le paramètre nbbytypes DEVRAIT avoir pour valeur par défaut 0, ce qui correspond pas de limite~~
    • [R09.7] : ajout
    • [R10] : nbbytypes => limit
    • [R10.1] suppression : ~~le bouton voir plus DEVRAIT recharger la page pour n'afficher que les résultats de la catégorie concernée mais sans limite de nbbytypes (en gardant la limite de limit)~~
    • [R10.2][R10.3]: ajout
    • [R11.1] suppression : ~~un handler avec le nom /anchor PEUT être créé afin d'ajouter à la volée une ancre pour faciliter la navigation~~
    • [R11.2] suppression : ~~un handler /anchoriframe PEUT être aussi créé pour le contexte iframe~~
    • 2022-09-07 [JD]:
      • [R07.2] : suppression de
        • ~~tagonpage:<nom-du-tag> (ex: tagonpage:catégorie: 1 pour le tag catégorie: 1 concernant que les pages)~~
        • ~~tagonforms:<nom-du-tag> (ex: tagonforms:catégorie: 3 pour le tag catégorie: 3 concernant que les fiches)~~
        • ~~tagonformXX,XX:<nom-du-tag> (ex: tagonform1,33:catégorie: 3 pour le tag catégorie: 3 concernant que les fiches des formulaires 1 et 33)~~
        • [R09.3] : valeur par défaut 10 (au lieu de différencier pour chaque template)
        • [R11.3] : ~~$_GET['search_anchor']~~ => $_GET['searchAnchor']

    Ce que fait la branche en l'état

    • refactor de {{newtextsearch}}
    • création d'un nouveau template avec affichage par colonne des résultats groupés par formulaire
    • ajout des paramètres existant dans advanced-actions.yaml
    • ajout des nouveaux paramètres liés au nouveau template
    • l'affichage est maintenant dynamic

    Pour tester la branche en l'état

    • dans une page, utilisez le bouton composants > Actions avancées > Recherche de texte pour ajouter l'action {{newtextsearch}}
    • régler à votre convenance les nouveaux paramètres
    • faire une recherche et apprécier
    opened by J9rem 22
  • Doryphore: Bazar API

    Doryphore: Bazar API

    toutes les url commençant par ?api renvoient une 401. https://gogowiki.teritorio.xyz/?api/fiche/1

    Et depuis le dashboard bazar, le lien vers l'api JSON est incorrect, il renvoie vers ?api/fiche/FORM_ID au lieu de ?api/form/FORM_ID

    opened by seballot 22
  • Problème MAJ Doryphore

    Problème MAJ Doryphore

    Type of issue (keep only one) / Type de demande (ne garder qu'une ligne) New feature / Nouvelle fonctionnalité Bug / Bogue

    Description Suite à une mise à jour de wikis vers la version doryphore 2021-01-11-3, écran blanc (un des wikis est tout neuf, sans contenu original, justement pour tester)

    Additionnal informations / Informations complémentaires

    • doryphore 2021-01-11-3
    • http://carto.hinaura.fr/?PagePrincipale
    • logs Fatal error: Uncaught Error: Call to undefined function YesWiki\loadTemplates() in /srv/data/web/vhosts/carto.hinaura.fr/htdocs/includes/YesWiki.php:1776 Stack trace: #0 /srv/data/web/vhosts/carto.hinaura.fr/htdocs/includes/YesWiki.php(97): YesWiki\Wiki->loadExtensions() #1 /srv/data/web/vhosts/carto.hinaura.fr/htdocs/index.php(69): YesWiki\Wiki->__construct() #2 {main} thrown in /srv/data/web/vhosts/carto.hinaura.fr/htdocs/includes/YesWiki.php on line 1776
    opened by hadide 20
  • Display content depending on ACL

    Display content depending on ACL

    Type of issue (keep only one) / Type de demande (ne garder qu'une ligne) New feature / Nouvelle fonctionnalité

    Description Si ça n'existe pas déjà ce serait super d'avoir une action qui permette d'afficher du contenu (bouton, HTML, ou autre...peu importe) uniquement pour tel ou tel utilisateur (suivant une ACL quoi). Dans mon cas par exemple je souhaite afficher un bouton "ajouter un évènement" à un calendrier qui mène vers la bonne page d'admin mais que ce bouton ne s'affiche que pour les @admins évidemment.

    Additionnal informations / Informations complémentaires

    • version of YesWiki / version de YesWiki Doryphore
    opened by toddoli 20
  • Change licence of YesWiki from GPL to AGPL

    Change licence of YesWiki from GPL to AGPL

    YesWiki est de plus en plus installé comme une plateforme de service SAAS, et afin de pouvoir bénéficier des modifications de code sur les plateforme, il nous faudrait utiliser la licence AGPL. cf. https://www.gnu.org/licenses/why-affero-gpl.html

    Pour éviter de devoir faire un fork sous cette licence, il faudrait que tous les contributeurs de YesWiki consentent au passage à cette licence.

    Pour cela il nous faudrait le consentement explicite des contributeurs suivants: @mrflos @daviddelon @Cyrille37 @gatienbataille @daiko @furax37 @LouiseQuincaillere @sylvainboyer @flabastie @acheype @jpmilcent @srosset81 @benrubson @sudwebdesign @geigerni

    Merci de laisser un commentaire avec votre consentement... ... ou pas ;)

    opened by mrflos 20
  • L'authentification d'un utilisateur ne persiste pas une fois la session du navigateur terminée

    L'authentification d'un utilisateur ne persiste pas une fois la session du navigateur terminée

    Type of issue (keep only one) / Type de demande (ne garder qu'une ligne) Bug / Bogue

    Description Voici un cas d'utilisation pour reproduire le bug sur un environnement de dev local :

    • je me connecte en n'oubliant pas et note l'heure (par exemple 14:00)
    • une fois connecté, je rafraîchis la page ce qui confirme que les informations de sessions sont retrouvées
    • je change l'heure du serveur (je mets 1h30 de plus pour être sûr que la session soit expirée)
    • en réactualisant la page, quand je clique sur la roue crantée, je vois que je ne suis plus connecté

    Sur mon ordinateur, c'est au bout d'un peu plus de 30 minutes que la session expire. Mais théoriquement, ce semblerait que ce soit la valeur qui soit inscrite dans le php.ini de l'apache du serveur à la variable session.gc_maxlifetime. Celle-ci est définie par défaut à 14400 (24 minutes) et c'est la valeur que j'ai chez moi.

    Tant que la session n'est pas expirée, la variable $_SESSION contient bien une clé user mais ensuite c'est le cookie qui devrait prendre le relais mais la variable $_SESSION est ensuite vide. Pourtant, je peux vérifier dans la console de dév de mon navigateur que j'ai bien le cookie YesWiki-main. Au niveau du code, le chargement des données de la session se fait au session_start() ici. C'est donc suite à cette instruction que je constate que je n'ai plus la clé user quand la session est expirée. Normalement la donnée devrait être ensuite copié (c'est censé être le comportement par défaut de PHP) au niveau d'un fichier (pour info, le cookie contient uniquement une clé qui permet d'identifier à qui appartient les données).

    Suite à la lecture de cet article qui stipule qu'il ne faut pas laisser un session_start() ouvert sans avoir fait un session_write_close() (car cela peut provoquer des blocages d'accès aux données de la session), j'ai suivi cette piste en me disant que session_write_close() allait peut-être permettre d'écrire les données dans ce fameux fichier (et ne pas rester seulement en mémoire), mais après de nombreux tests, en essayent également de changer la façon dont on fait les paramétrages de la session, j'obtiens toujours le même soucis.

    Sur ce sujet de forum, la personne a lui même détecté quand la session est expirée mais qu'il y a toujours le cookie et charge le cookie manuellement... J'ai l'impression que php devrait justement s'occuper de cela mais lui a résolut le soucis de cette manière.

    Additionnal informations / Informations complémentaires

    • 4.3.1, doryphore-dev, et toutes les versions depuis septembre (en gros)
    opened by acheype 13
  • feat(CommentsField): create

    feat(CommentsField): create

    cette PR ajoute le champ comments

    ce que ça fait:

    • ajouter le champ comments
    • en suivant les spécifications de https://pad.lescommuns.org/C7vddagURFGIbraoE_Z02Q# (lien temporaire)

    ~~attention cette PR pointe vers la branche coms-improvement vu que c'est très lié~~

    opened by J9rem 10
  • Configurer les paramètres d'une action

    Configurer les paramètres d'une action

    Avant de continuer à refactorer toutes les actions vers la nouvelle syntaxe en classe, je pense qu'il y quelque chose à faire sur la déclaration des paramètres (i.e. arguments) de l'action

    Jérémie et Adrien avait déjà cerné le problème et ont mis en place une fonction formatArguments

    Je pense qu'on peut aller plus loin et faire quelque chose de plus générique et DRY

    Proposition

    S'inspirer de la syntaxe symfony pour déclarer les argument des commandes symfony

    Exemple pour l'action Button

    class ButtonAction extends YesWikiAction
    {
      public function configure()
      {
          $this
              ->addArgument("link", UrlArgument, ["required" => true])
              ->addArgument("text", TextArgument, ["required" => true])
              ->addArgument("hideifnoaccess", BooleanArgument, ["default" => true]);
      }
      
      // ...
    }
    

    Et on peut déclarer les types d'argument avec quelque chose comme

    class Argument
    {
        public function format($arg)
        {
            return $arg;
        }
    }
    
    class TextArgument extends Argument {}
    class UrlArgument extends TextArgument {}
    
    class BooleanArgument
    {
        public function format($arg)
        {
            return in_array($arg, ["true", "1"]);
        }
    }
    

    Traitement automatisés

    Avec cela on pourra automatiquement détecter et mettre une alerte sur les argument obligatoire non rempli, assigner les valeurs par default, et faire le formattage/parsing des arguments un peu spéciaux genre groups ou displayfields en créant un nouveau type d'argument

    Inherit from another action

    L'avantage avec la function configure c'est qu'on peut faire des trucs genre

    class CustomButtonAction extends ButtonAction
    {
      function configure()
      {
         parent::configure();
         $this
           ->removeArgument('text');
           ->updateArgument("link", UrlArgument, ["required" => false]);
           ->addArgument("newarg", TextArgument);
      }
    }
    

    Documentation automatisée

    L'autre avantage c'est qu'on peut récupérer les infos déclarées dans configure pour les utiliser dans l'action builder. C'est notament important pour les valeur par default, car si dans la doc yaml on met que la valeur par défault d'un argument est "true" et que dans l'action php l'argument est par défault initialisé à "false", ça fait un peu tout foirer

    Mais je pense qu'on va quand meme garder les fichier yaml car il y aura toujours des config qui trouveront difficilement leur place dans le configure notamment la description des groupe d'actions Mais on pourrait fusionner les deux config, par pour le button;yaml on pourrait garder cette config

    # buttons.yaml
    label: _t(AB_buttons_label)
    position: 2
    previewHeight: 100px
    actions:
      button:
        label: _t(AB_buttons_action_button_label)
        description: _t(AB_buttons_action_button_description)
        properties:
          text:
            label: _t(AB_buttons_action_button_text_label)
            value: _t(AB_buttons_action_button_text_default)
          link:
            label: _t(AB_buttons_action_button_link_label)
            value: https://yeswiki.net
            hint: _t(AB_buttons_action_button_link_hint)
            type: page-list
         hideifnoaccess:
            advanced: true
            label: _t(AB_buttons_action_button_hideifnoaccess_label)
    

    Et on la compléterai avec les infos définies dans le configure

    Donc la y'aurait un arbitrage à faire avec ce qu'on met dans le configure et ce qu'on met dans le yaml. Car on pourrait très bien dans configure faire

    public function configure()
    {
        $this->addLabel(_t("AB_buttons_action_button_label"));
        $this->addArgument("text", UrlArgument, [
            "required" => true,
            "label" => _t("AB_buttons_action_button_text_label"),
            "value" => _t("AB_buttons_action_button_text_default"),
            "advanced" => false
        ]);
    }
    

    Perso je laisserai le max dans le yaml, et mettrai juste ce qui permet le traitement automatique des arguments, donc le type, si c'est required, et si y'a une valeur par default.

    proposition concertation 
    opened by seballot 0
  • Personnaliser le rendu d'une fiche bazar

    Personnaliser le rendu d'une fiche bazar

    En prévision d'un futur sprint

    L'idée est de pouvoir facilement personnaliser le rendu d'une fiche bazar depuis l'interface sans avoir à créer un fichier sur le serveur dans custom/templates

    Proposition

    Lorsqu'on édite un formulaire, on pourrait rajouter un nouvel onglet "Rendu des fiches" avec un éditeur wiki dedans Dans cet éditeur, en plus des fonctionnalités classique lorsqu'on édite une page, il faut pouvoir :

    1. Accéder aux valeurs brutes des champs de la fiche
    2. Afficher un champ tel qu'il aurait été affiché de manière automatique en html
    3. Accéder à la config du formulaire
    4. Ecrire directement du twig

    Syntaxe/Implémentation

    Prenons un exemple : pour un formulaire avec un bf_titre, bf_equipe, bf_url et bf_categories (de type checkboxes), je veux -> afficher un titre avec bf_titre et bf_equipe dedans -> afficher un bouton qui renvoie vers bf_url -> afficher les catégories de manière automatique

    Moustaches

    Note: Il faudra ajouter une option lors du Formatter wakka pour dire "si l'action n'est pas trouvée, laisse le texte comme ça" plutot que de mettre le message "Action bf_titre n'existe pas" Avantages: Ca ressemble à une syntaxe classique yeswiki, et on peut écrire du twig Inconvenient: L'autocompletion quand on tape {{ mélangera le nom des actions et le nom des champs. Ou alors dans ce contexte on désactive l'autocompletion du nom des actions.

    ==={{bf_titre}} - {{bf_equipe}}===
    {{button link="{{bf_url}}" text="Site web"}}
    {{field id="bf_categories" label="Les catégories"}}
    
    {# Autre exemple avec twig #}
    ""
    <h1>{{ bf_titre|uppercase }} - {{bf_equipe}}</h1>
    
    {% for option in bf_categories %}
    	<li>Category value = {{ option }} label = {{ form.bf_categories.options[option] }}
    {% endfor %}
    ""
    

    Crochets

    Avantages: Pas de conflits de syntaxe. On peut facilement faire de l'autocompletion Inconvenient: Pour twig, faudrait changer le delimiteur

    ===[[bf_titre]] - [[bf_equipe]]===
    {{button link="[[bf_url]]" text="Site web"}}
    {{field id="bf_categories" label="Les catégories"}}
    
    {# Autre exemple avec twig #}
    ""
    <h1>[[ bf_titre|uppercase ]] - [[bf_equipe]]</h1>
    
    [% for option in bf_categories %]
    	<li>Category value = [[ option ]] label = [[ form.bf_categories.options[option] ]]
    [% endfor %]
    ""
    

    Variantes pour l'affichage du rendu automatisé d'un champ

    {{render field="bf_categories" label="Les catégories"}}
    {{bazarfield id="bf_categories" label="Les catégories"}}
    {{bazarentry field="bf_categories" label="Les catégories"}}
    

    Spécifier de quelle manière on veut faire le rendu

    Par default ça utilise le type de champ déclaré dans le formulaire

    {{field id="bf_url" as="text" label="l'url en mode plain text"}}
    

    Petit extra

    Un bouton special dans la toolbar pour selectionner quel champ on veut afficher et que ça insère {{bf_equipe}} dans l'éditeur quand on selectionne bf_equipe dans la popup

    Personnaliser aussi le bazarliste

    On pourrait utiliser la même syntaxe mise en place afin de personaliser le rendu des bazarliste. Pour le template card par example, plutôt que de dire "dans la zone de titre affiche le champ bf_titre" on pourrait dire "dans la zone de titre affiche le rendu de Equipe {{bf_titre}} ({{bf_equipe}})

    proposition concertation 
    opened by seballot 1
  • Problème d'affichage de fiches liées

    Problème d'affichage de fiches liées

    Type of issue (keep only one) / Type de demande (ne garder qu'une ligne) Bug / Bogue

    Description Lors de l'affichage des données d'un formulaire, la liste des fiches liées aux fiches du formulaire ne s'affiche pas lorsque le paramètre dynamic="true" est présent dans bazarliste (en revanche elles s'affichent bien lorsqu'on les ouvre depuis Base de données).

    {{bazarliste id="46" template="liste_accordeon" filtersresultnb="false" dynamic="true" groups="listeListeBlocDeCompetences" }}

    Lorsque l'on supprime dynamic="true", les fiches liées apparaissent.

    {{bazarliste id="46" template="liste_accordeon" filtersresultnb="false" groups="listeListeBlocDeCompetences" }}

    Additionnal informations / Informations complémentaires

    • version of YesWiki / version de YesWiki doryphore : 4.2.4

    • url to see the problem or an example / url pour voir le probleme ou un exemple : https://www.cerealocales.org/?ExpertisesListe

    • screenshot / capture d’écran Avec dynamic="true" : screen_avecfichesliees Sans dynamic="true" : screen_sansfichesliees

    • logs

    opened by TimotheeINRAE 4
  • Login : pouvoir voir son mot de passe quand on le tape

    Login : pouvoir voir son mot de passe quand on le tape

    Type of issue (keep only one) / Type de demande (ne garder qu'une ligne) New feature / Nouvelle fonctionnalité

    Description Il serait utile de pouvoir avoir une vue des caractères tapés lors de la saisie du mot de passe (au clic sur un icone à droite par exemple) comme cela se fait habituellement dans ce type d'interface.

    Demande remontée par utilisatrice rencontrée dans le cadre d'animacoop

    opened by RomainLalande 1
Owner
YesWiki
French NGO YesWiki - Association loi 1901
YesWiki
BookStack is an opinionated wiki system that provides a pleasant and simple out of the box experience.

BookStack is an opinionated wiki system that provides a pleasant and simple out of the box experience. New users to an instance should find the experience intuitive and only basic word-processing skills should be required to get involved in creating content on BookStack. The platform should provide advanced power features to those that desire it but they should not interfere with the core simple user experience.

BookStackApp 10.6k Jan 2, 2023
Manage your photos with Piwigo, a full featured open source photo gallery application for the web. Star us on Github! More than 200 plugins and themes available. Join us and contribute!

Manage your photo library. Piwigo is open source photo gallery software for the web. Designed for organisations, teams and individuals. The piwigo.org

Piwigo 2.3k Jan 1, 2023
e107 Bootstrap CMS (Content Management System) v2 with PHP, MySQL, HTML5, jQuery and Twitter Bootstrap

e107 is a free and open-source content management system (CMS) which allows you to manage and publish your content online with ease. Developers can save time in building websites and powerful online applications. Users can avoid programming completely! Blogs, websites, intranets – e107 does it all.

e107 Content Management System 298 Dec 17, 2022
PressDoWiki - Fast & Light PHP Wiki Engine

PressDoWiki - Fast & Light PHP Wiki Engine 이 위키는 현재 제작 중입니다. Currently in development. the seed와 최대한 유사하게 구현하는 것을 목표로 하고 있는 PHP 위키 엔진입니다. 요구 사항 (Requi

PressDo 18 Nov 25, 2022
Google Maps Plugin for Typemill CMS.

Google Maps Plugin This plugin is developed for Typemill, a flat-file cms. How to install Download this plugin (zip). Unzip the plugin. Upload the plu

Nico 1 Jun 1, 2022
A Simple and Lightweight WordPress Option Framework for Themes and Plugins

A Simple and Lightweight WordPress Option Framework for Themes and Plugins. Built in Object Oriented Programming paradigm with high number of custom fields and tons of options. Allows you to bring custom admin, metabox, taxonomy and customize settings to all of your pages, posts and categories. It's highly modern and advanced framework.

Codestar 241 Dec 23, 2022
Create WordPress themes with beautiful OOP code and the Twig Template Engine

Timber helps you create fully-customized WordPress themes faster with more sustainable code. With Timber, you write your HTML using the Twig Template Engine separate from your PHP files.

Timber 5.2k Dec 31, 2022
Boilerplate used to build nearly-headless WordPress themes

Boilerplate for Nearly Headless WordPress Themes This is a plugin boilerplate built using Underpin ,Nicholas, and AlpineJS. It will allow you to build

Nicholas 103 Dec 22, 2022
Add subtitles into your WordPress posts, pages, custom post types, and themes. No coding required.

Add subtitles into your WordPress posts, pages, custom post types, and themes. No coding required. Simply activate Subtitles and you're ready to go.

We Cobble 117 Dec 31, 2022
Typecho Themes,bestgril

bestgirl Typecho Themes,bestgirl主题 主题简介 bestgirl主题是一款简约风格的响应式轻主题,基于鹅厂熊大的出租本人创意域名展示页。 此主题适合日志、轻言、诗词、语录、格言、名句、条目、菜谱、记事本、大事记、回忆录等各种轻简短文字类网站。 主题预览 链接:http

null 38 Nov 14, 2022
PHPDish is a powerful forum system written in PHP. It is based on the Symfony PHP Framework.

PHPDish 是一个基于Symfony框架开发的内容社区系统;得益于大量的前端以及后端的第三方类库的使用使得PHPDish有着高质量的代码,敏捷实现; 你可以使用composer或者直接下载本仓库进行程序的安装,注意切换到tag。 PHPDish 开发手册以及详细安装文档 Requirements

PHPDISH 227 Dec 8, 2022
PHPDish is a powerful forum system written in PHP. It is based on the Symfony PHP Framework.

PHPDish 是一个基于Symfony框架开发的内容社区系统;得益于大量的前端以及后端的第三方类库的使用使得PHPDish有着高质量的代码,敏捷实现; 你可以使用composer或者直接下载本仓库进行程序的安装,注意切换到tag。

PHPDISH 227 Dec 8, 2022
A drop in replacement for Symphony CMS to upgrade core and selected extensions to PHP 8.0 compatibility

PHP 8 Upgrade Instructions These are the files I have used to upgrade existing Symphony CMS installs to PHP 8.0 compatibility. As always, make sure yo

Phill 3 May 25, 2022
Simple Bootstrap Laravel CMS. Support Laravel 8.x Can integrate into any existing Laravel project.

Simple Bootstrap Laravel CMS. Support Laravel 8.x Can integrate into any existing Laravel project. Only add few database tables with prefixes, not affect your existing database tables. Support Laravel 7.x & Laravel 6.x & Laravel 5.x & MySql & PostgreSql - Amila Laravel CMS

Alex Zeng 96 Sep 6, 2022
Amila Laravel CMS - Free, open-source Simple Bootstrap Laravel CMS

Simple Bootstrap Laravel CMS. Support Laravel 8.x Can integrate into any existing Laravel project. Only add few database tables with prefixes, not affect your existing database tables. Support Laravel 7.x & Laravel 6.x & Laravel 5.x & MySql & PostgreSql - Amila Laravel CMS

Alex Zeng 96 Sep 6, 2022
Multilingual PHP CMS built with Laravel and bootstrap

Lavalite This is an open source of Content Management System developed with Laravel framework. Documentation Visit Documentation section in the websit

LavaLite 2.6k Jan 4, 2023
Bootstrap CMS - PHP CMS powered by Laravel 5 and Sentry

Bootstrap CMS Bootstrap CMS was created by, and is maintained by Graham Campbell, and is a PHP CMS powered by Laravel 5.1 and Sentry. It utilises many

Bootstrap CMS 2.5k Dec 27, 2022
NukeViet 132 Nov 27, 2022
b5st – A Bootstrap 5 Starter Theme, for WordPress

b5st – A Bootstrap 5 Starter Theme, for WordPress Version 1.1 https://github.com/SimonPadbury/b5st b5st is a simple, Gutenberg-compatible WordPress st

Simon Padbury 29 Dec 20, 2022