
Recherche avancée
Médias (1)
-
SWFUpload Process
6 septembre 2011, par
Mis à jour : Septembre 2011
Langue : français
Type : Texte
Autres articles (112)
-
Script d’installation automatique de MediaSPIP
25 avril 2011, parAfin de palier aux difficultés d’installation dues principalement aux dépendances logicielles coté serveur, un script d’installation "tout en un" en bash a été créé afin de faciliter cette étape sur un serveur doté d’une distribution Linux compatible.
Vous devez bénéficier d’un accès SSH à votre serveur et d’un compte "root" afin de l’utiliser, ce qui permettra d’installer les dépendances. Contactez votre hébergeur si vous ne disposez pas de cela.
La documentation de l’utilisation du script d’installation (...) -
Demande de création d’un canal
12 mars 2010, parEn fonction de la configuration de la plateforme, l’utilisateur peu avoir à sa disposition deux méthodes différentes de demande de création de canal. La première est au moment de son inscription, la seconde, après son inscription en remplissant un formulaire de demande.
Les deux manières demandent les mêmes choses fonctionnent à peu près de la même manière, le futur utilisateur doit remplir une série de champ de formulaire permettant tout d’abord aux administrateurs d’avoir des informations quant à (...) -
La sauvegarde automatique de canaux SPIP
1er avril 2010, parDans le cadre de la mise en place d’une plateforme ouverte, il est important pour les hébergeurs de pouvoir disposer de sauvegardes assez régulières pour parer à tout problème éventuel.
Pour réaliser cette tâche on se base sur deux plugins SPIP : Saveauto qui permet une sauvegarde régulière de la base de donnée sous la forme d’un dump mysql (utilisable dans phpmyadmin) mes_fichiers_2 qui permet de réaliser une archive au format zip des données importantes du site (les documents, les éléments (...)
Sur d’autres sites (7799)
-
Evolution #4653 (Nouveau) : : remplacer le webservice en image fixe par MathJax en local ?
9 février 2021, par RastaPopoulos ♥I y a déjà le plugin https://contrib.spip.net/MathJax-pour-SPIP
qui remplace la génération côté serveur en image fixe par une transformation en JS et qui produit donc du contenu directement dans le DOM, suivant les CSS.MathJax est à priori très maintenu, et il est même accessible aux lecteurs d’écran ! Du coup est-ce qu’il y a encore une raison de maintenir un webservice au lieu de mettre à jour le plugin et l’intégrer aux dist ?
https://www.mathjax.org/Cette lib est soutenu par la Société américaine des maths… par l’IEEE, Elsevier, Oxford… et moult autres noms prestigieux… Je pense qu’on peut raisonnement lui faire confiance pour afficher correctement les formules de maths non ?
Plus de webservice à maintenir, et moins d’infos des utilisateurs envoyés à un service tiers (fut-il à nous)
-
Anomalie #3205 (Nouveau) : [Plugin-dist Mots] Incompatibilité avec l’API d’édition d’objet ?
13 avril 2014, par charles razackIl semblerait que la création d’un groupe de mots par le biais l’API d’édition d’objet ne fonctionne pas.
A première vue, on dirait que c’est dû à un souci de nommage de fonctions au niveau du plugin.Pour reproduire, dans le traitement d’un formulaire par ex. :
include_spip('action/editer_objet');<br />$set = array('titre'=>'Mon super titre',, 'tables_liees'=>'articles');<br />$id_groupe = objet_inserer('groupe_mots', '', $set);
var_dump($id_groupe);
renvoieNULL
et pour cause : le groupe de mots n’a pas été créé.Cause probable :
Dans le fichier
action/editer_groupe_mots.php
du plugin, les fonctions sont nomméesgroupemots_xxx()
au lieu degroupe_mots_xxx()
,
ce qui fait que la fonctionobjet_inserer()
de l’API ne les trouve pas.
Du coup elle tente une insertion "générique" qui pour une raison ou une autre ne fonctionne pas (pb avec sql_insertq ligne 209, je n’ai pas regardé ce qui cloche exactement). -
Revision 109633 : Ma console réseau de mon navigteur indique : - jquery-ui.js : 508,86ko ...
22 mars 2018, par placido@… — LogMa console réseau de mon navigteur indique :
jquery-ui.js : 508,86ko
jsdyn-formulaires_dateur_jquery_dateur_js_14fce12d.js : 517,89 ko
Le fichier js dynamique est chargé via $.getScript depuis le fichier formulaire/dateur/inc-dateur.html qui inclut déjà lui-même jquery-ui !
On se retouve donc avec une double dose d’un jquery-ui (déjà pachidermique) à la moindre saisie date appelée. C’est clairement un problème.
Je m’interroge sur la nécessite de l’insertion des css et js via affichage_final. Sauf cas particulier qui m’échappe, je pense que cette fonction saisies_affichage_final n’a pas (plus) lieu d’être.
Je propose d’opter pour un chargement des éléments globaux via insert_head et insert_head_css (sans jquery-ui) et pour les cas particuliers, cela doit se gérer au niveau du squelette de la saisie (à l’instar de ce que fait déjà la saisie date qui fait un #INCLURE de inc-dateur.html).
En attendant des avis, on peut déjà rendre cette fonction surchargeable (désactivable).