Forum CMS Made Simple FR

Version complète : Reflexion: CmsMs / (blocs de contenu) /jquermobil et grids
Vous consultez actuellement la version basse qualité d’un document. Voir la version complète avec le bon formatage.
Citation :#~~~~~ DEBUT BLOC A NE PAS SUPPRIMER ~~~~~
#~ Version du CMS: 1.11.9
#~ Url du site :
#~ Hébergeur / Soft :
#~ Informations Système :
#~~~~~ FIN BLOC A NE PAS SUPPRIMER ~~~~~



Bonjour,

Cela fait plaisir de voir qu'il y a de nouveau de la vie sur CmsMs (fr)


D'abord est-ce que quelqu'un a une idée, une vision de la prochaine version 2 qui doit sortir en jan /feb est-ce qu'il va y avoir des changements majeurs ?

Je poste ici mais en même temps c'est une réflexion un peu récurrente:

Suite à un post récent encore sur la question
http://www.cmsmadesimple.fr/forum/viewto...362#p37362

je me demande vraiment comment on peut faire une synthèse correcte des moyens à utiliser pour créer un contenu de type éditorial sans éditeur ?

de genre article
titre chapeau
image /gauche
texte/ /droite

Naturellement on parle de Advanced content, de content image de CGutilscontents.

Perso j'ai déjà expérimenté Advanced content, et je trouvais OK malgré que pour gérer dans l'admin, c'est pas très explicite (pour les users). et on se retrouve vite ensablé avec tout un tas de blocs de contenu

Je pensais qu'un jour on arriverait à un module comme chez Drupal ( le module CCK). mais c'est down

Si je vous parle de cela, c'est qu'aprés pas mal de veille sur internet, en particulier, sur la mise en page pour les mobiles, tablettes etc et de l'utilisation des grids.
Je reste convaincu que CMSMS reste très bon mais question mise en page, l'utilisation de certains modules devient impossible (trop de contraintes).

J'aimerais bien une réflexion la-dessus, car je continue de penser que CmsMs reste super (pour alimenter du contenu) et simple à utiliser en conjonction par exemple avec jquerymobil pour les menus dynamiques, mais je pense que CMSMS va avoir un gros prob si la "philosophie" des modules n'est pas révisée et revisitée très vite du fait de l'utilisation de plus en plus grandissante des snippets.

Les CMS ont en ce moment une grosse carte à jouer (plus facile avec les tablettes) mais moins évidente avec les mobiles.

Je vous assure que c'est á mon sens une question CRUCIALE et que ceux qui vont prendre le bon train seront dedans pour un bon moment.
C'est pour cela que je voudrais avoir ici des avis sur la question en particulier sur une ( mise en prod) efficace de modules dans des blocs de contenus pour des grids

Mise en page (bloc édito)
login
admin
gallerie etc ...
flux RSS

A+


PS: Franchement c'est un sacré défi, Wordpress n'aura bientôt plus sa place, trop gazé, trop spammé, Drupal reste une grosse machine, il y en d'autres(CMS) qui essaient:Gosht le petit pluxml réagit vite (blog 100% XML)
Une chose est sûre l'éditeur wything devient de plus en plus inutile et pas HTML5

Est-ce qu'on peut avoir une reflexion CmsMs/mobiles/jquerymobil pour ceusses que cela intéresse ?
That is the question.

Bonne journée A+
moi ça me dépasser un peu tout cela mais je reconnais que cmsms se retrouve limité dans un site ou l'utilisateur demande mille blocks dans tous les sens et pour cause : il n'est effectivement pas conçu pour ce public de rédacteur de journaux. Et je parle de rédacteur de journal car en dehors de cette catégorie de personne souhaitant maitriser le contenu et le design aussi finement, cmsms répond parfaitement aux besoins rédactionnels.

Autrement dit, même si c'est une part d'utilisateur montante, elle reste minoritaire. Il y a un train à prendre mais ne risque t on pas de perdre nos utilisateurs actuel à vouloir s'inventer un nouveau marché ? WP subit de plein fouet ce changement de cap blog -> cms, il faut rester très précautionneux avec cela.

Maintenant comme j'ai dit en début de message : c'est un sujet qui me dépasse un peu Wink

Et sinon pour la 2.0 c'est la gestion du contenu qui est remise à plat dans la mesure ou tous les gabarits vont être rassemblés au même endroit. Zéro CCK en vue et heureusement selon moi (et mes besoins) car le CCK est la principale source d'emmerde de Drupal niveau perf sur les grosses plateformes qui nécessitent une optimisation énorme de la bécane, de PHP, de mysql et du cache à tous les niveaux. (dixit l’architecte php/front de ma boite)
Salut Bess,

Tu as certainement raison pour CCK, mais je continue à penser qu'un petit CCK faut mieux que beaucoup de blocs tu auras.
Laissons tomber cela je ne cherche pas à me compliquer la vie ni à charger la mule.

En fait plus je me simplifie et plus c'est mieux
Indispensable pour ceux qui ne connaissent pas; chez Alsace
tutorial Knacss
/*--------------------------------------------------------------------------------------------*/

La réflexion porterait plutôt sur l'aliage

jquerymobil, qui est un outil très pratique pour gérer boutons , menus, bar, tous les élements utiles à la navigation sur mobile. tout cela est dans un pack facile à gérer, condensé, optimisé.

un framework/gabarit (léger.) plus adapté ipad /mobile

et CmsMs pour envoyer et gérer du petit contenu (vidéo/gallerie/news) d'ou l'unitilité de certains gros modules

Par contre le plus important ce sont certains modules qui eux doivent (coller) au grid fluid ou responsive

-News (les gabarits de sommaires doivent être super optimisés)
-login
-gallery
-uploads (jquery).

/*---------------------------------------------------------------------------------------------------------------------------------------*/

CMSms reste de toute facon Ok pour les desktops laptops, l'enjeu se situe plus sur les tablettes, ipad, iphone, mobiles qui deviennent incontournables.
Il ne s'agit pas de proposer autant d'options que sur un site (grand écran) mais des options d'appel avec des news, du petit contenu de la vidéo, de l'image qui raméne vers le site principal.
D'ou la nécessité d'avoir trois quatre modules qui roulent correctement sur (les grids).
Donc il n'y a pas de nouvauté flagrante mais juste une nouvelle orientation Mobile

Certains diront que le (responsivité) suffit amplement à gérer cela
personellement si je fais un site large, je peux envisager la responsivité mais pour les autres je préfère un browser sniffer
et un grid adapté au support (Ipad/mobile)

Après un réel engouement du début pour Bootstrap, je préfère maintenant de loin la solution Boilerplate/jquerymobil plus légère et plus souple et réellement optimisée.
Ce qui est vraiment galère avec les framework, c'est que si on part de rien ou presque au niveau css avec Knacss par exemple qui est excellent, mais après faut s'appeler Alsace création pour optimiser (je parle surtout de navigation sur les mobiles); bon si c'est un petit site ca va encore.

Si on utilise Bootstrap ou autre fondation, on a plus accès à rien.
Il y a quelque temps j'avais vu sur le forum, je sais plus si c'était Aairlibre ou Jissey:
Un module compil de css ???
Cela reste un soucis sur cmsms si on doit mettre au gabarit une ou deux feuilles de style et importer le reste.

Donc le débat est ouvert
Modules sur le grid
compil/ css
Framework (mobile)/
perso;je reste sur jquerymobil pour la navigation; bar, navbar, boutons, form, icons, fleches, thumbnail, footer, menu
Ouh la la no dèbate !

Mes constatations sont les suivantes
l'intégration de jquerymobile dans CMSMS est fastoche de plus le résultat est spectaculaire
controlé sur
http://www.browserstack.com/screenshots/...1861157d3e.
ca passe sur tous les suports
De plus les possibilités dans jquerymobil sont grandioses

Le seul HIC à toute cette beauté c'est la détection
j'avais trouvé ceci et j'étais plutôt content
http://www.i-do-this.com/blog/14/Make-yo...bile-ready de chez Goran
mais pas moyen d'afficher la partie mobile

y'avait aussi le plugin tjrs de chez Goran
https://github.com/uniqu3/mobiledetect

Donc actuellement je n'arrive plus à rien, si cela intéresse quelqu'un je suis prêt à communiquer.

A+ bon week end
hello,
sans trop entrer dans le débat pour ne pas faire de troll, j'utilise avec bonheur depuis quelques mois Bootsrap 3 qui permet une adaptation sans faille sur tout type d'écran. La question de la detection ne se pose pas dans ce cas.
La gestion du menu est optimisée et la V3 apporte une gestion fine au niveau GRID en fonction de la taille de l'écran.
Elle est mobile first et responsive par défaut.
Sinon, la V2 de CMSMS proposera la gestion des contenus dans un module CMSContentManager, ce qui permettra aux développeurs de créer leur propre module, donc type de contenu (dixit Calguy je ne sais plus dans quel billet).

edit : C'est Exacore qui propose un module pour faire du less, donc bootstrap.
Salut jissey (respect)

...J'ai d'abord foncé tête baissée dans bootstrap (tout le monde en parlait), je me suis mis vite fait à la 3, vu que que j'avais pris la 2 sur la fin par contre
j'ai assez vite déchanté quand j'ai senti la lourdeur et la charge des scripts de plus j'ai pas senti dans la doc trop (d'opportunités) sur la navigation et en plus les (users) de mac se plaignent de la déco minimale et la communauté s'est refroidie après le passage sur la trois

J'ai donc cherché ailleurs et je suis tombé par hasard sur une vidéo qui présentait un peu l'avenir en matière de css et de dom js et html5, notamment sur les( components des hlists du shadowhost.)
Du coup en cherchant je suis tombé sur jquerymobil au début j'étais septique mais j'ai vite découvert la puissance.

#D'abord seulement 3 scripts qui embarquent pratiquement la totalité 1 css et 2 js qui embarquent presque tout ce dont on a besoin donc on cherche pas à raccrocher de la css et du js en queueleuleu en se demandant tjrs c'est qui qui fait quoi.

Pour le grid
c'est encore plus simple la division se fait avec des lettres comme le reste d'ailleurs, cela fait qu'on n'a pas besoin de se casser à configurer du grid 12 16 24 48, on a (a, b, c, d,e) avec un (grid_ui
_b) on a l'écran d'un mobil ou ipad coupé en deux.

La doc est bonne hyper bien faite très bien concentrée, les poss de navigation sont énormes tout en ajax (j'y connais rien en Ajax et c'est encore plus beau quand on s'en occupe pas). Comparées à bootstrap, les démos sont très propres et les (class sont super classes).

Aprés avoir pas mal lu, je crois comprendre que le Less ou le sass n'a pas trop d'avenir.
jquerymobil fait tout d'entrée tout est dèja compilé(c'est le shadowhost), il suit exactement la même dénomination que bootstrap3, les menus sont en hlist aussi et il propose un site ou on peut reprendre les globales, les couleurs arrondis etc et remettre tout ca dans une css thème et pour avoir la dernière version suffit juste de changer les numéros en fin de script (tjrs à jour)

Bon j'insiste pas plus là-dessus.

boosstrap 3 (mobile first) ok le reste après; en plus bonjour les .col-md-4-sm6-xs 12 .col-lg-2 (mamamia).
/*-------------------------------------------------------------------------------------------------------------------------------------*/
La question de la detection ne se pose pas dans le cas, du mélange xs et de lg (perso j'ai du mal à saisir les correspondances (si tu as un lien vers une doc (pas celle de bootstrap) qui explique vraiment les correspondances de toute facon je crois qu'au final c'est très dur à configurer (les divisions) pour les très petits écrans et on a tout à la queue leu leu alors que jquerymobil te fait les (subdivisions ) en un clin d'oeil: C'est désarmant de simplicité
ui_grid_a block _a(100%) ui_grid_b block_b (2 blocks50%).

-On a pas franchement besoin de deux gabarits (c'est responsive aussi) mais le systhème de menu/list est plus basé sur de l'accordéon donc assez moche sur grand écran mais ils viennent de sortir une classe en surcouche pour des menus facon boutstrap

Donc au final et j'en suis là il vaut mieux détecter un gabarit ou {else} l'autre pour quelqu'un qui touche un peu surtout avec les Udts et les {if} cela ne doit pas être trop dif, (d'autant plus qu'il y a déjá un plugin (mobiledetect,et une UDT)moi ca me dépasse. Autant j'ai un côté artiste qui me permet de voir ce qui peut être bon pour libérer la créativité
autant la prog pure est dure me heurte pourtant j'en ai fait en troisD avec un langage proche du C sur un logiciel libre qui s'appelle (POV/mégaPOV)http://hof.povray.org/ mais les if/else je les aie dans le nez

Le reste jte promet c'est un vrai légo
Alsace création a fait une belle démo c'est une parmis tantd d'autres
http://www.alsacreations.com/tuto/lire/1...teurs.html.
....depuis les options de cache sont en native...

A***
Pour le LessCSS ou les autres préprocesseurs je n'arrive pas à comprendre en quoi ils n'auraient pas d'avenir. Bien au contraire, le simple fait d'essayer cette évolution du langage suffit à comprendre son intéret.
J'ai développé le module ExaCSS qui permet de travailler en CSS, LessCSS, sacss ou Crush-CSS. Il compile et compresse différents styles en un seul avec mise en cache. Je vous invite à essayer.

Je pense sincèrement qu'un site « responsive » suffit amplement pour proposer du contenu au « desktop », tablettes et smartphones. Deux façons de voir suivant le type de résultat souhaité : Mobile First ou Desktop First.

La détection du navigateurs est loin d'être une solution fiable pour un site. Je vous invite à lire cet article : http://letrainde13h37.fr/28/les-user-age...st-le-mal/

A mon sens un site qui n'est pas en mesure de s'adapter (RWD) à la lecture sur mobile comme sur smartphone c'est souvent la faute au contenu. Trop de contenu souvent...
Dans ce cas là ce n'est pas un problème de technologie mais de structure.

Certains intégrateurs ont trop tendance à proposer une expérience de navigation « dégradée » sur smartphone comparé au site « normal ». C'est illogique.
En quoi le fait que je surfe sur mobile devrait me pénaliser dans mon expérience de surf. Pourquoi n'aurais-je pas accès à une fonctionnalité depuis mon smartphone alors qu'il y a une heure, chez moi, je pouvais l'utiliser depuis mon bureau. C'est déroutant.

Sur la plupart des sites que je développe depuis quelques mois, je réfléchie au design mobile et desktop en même temps, au contenu adapté à ces différents terminaux, etc. Au final, l'objectif étant de fournir des sites plus intuitifs, des pages de contenu ciblé (bon pour le SEO en plus), une architecture et structure des pages simplifiées, etc.
Salut exacore,

Tes réactions sont tout á fait pertinentes et ton expérience et retour en tant que professionnel très utile
je vais essayer ton module qui doit être bien utile en ces temps de CSS de plus en plus chargées
Quand je disais que le Less ou SASS n'avaient pas d'avenir, cela est à mettre entre guillemets mais à terme je crois bien comprendre (vu le nombre de nouveaux supports) que le langage, l'écriture et le dom vont être graduellement refondus vers des langages de prog plus direct, c'est le cas pour pas mal de chose en ce moment comme dans les jeux.
Les nouvelles balise HTML5 deviendront des super balises de data qui interpreteront tout un ensemble d'élèments préècrits, compilés et masqués via les navigateurs, comme pour les nouveaux éléments audio et vidéo
/*---------------------------------------------------------------------------------------------------------*/

exacore a écrit :Je pense sincèrement qu'un site « responsive » suffit amplement pour proposer du contenu au « desktop », tablettes et smartphones. Deux façons de voir suivant le type de résultat souhaité : Mobile First ou Desktop First.

Faire un site sans lui donner la possibilité d'être vu sur un autre support est en effet un peu dommage, et la responsivité peut suffire dans bien des cas. donc on part du haut et on va vers le bas (en taille). Une réflexion amusante à ce propos, comme tout le monde est focalisé sur le (Grid 960), qui devient incontournable, alors qu'il les casse bien aux graphistes avec ses calculs de pourcentage à la con---15,ceci 8,cela. Un graphiste à eut la bonne idée de proposé un (Grid PSD) de max_width:100Opx; ainsi on a des comptes rond sur les dimensions des images; par EX;
6x15%=900+5x20px pour les guters/intervales. et le tour est joué; on voit bien que rien n'est figé.


En tant que pro tu vois et sens bien que la communication et l'utilisation du web sur les smartphones et autres tablettes n'est pas la même que sur un site traditionnel. Il faut utiliser des contenus courts (pas plus de 90secondes de lecture).
Du contenu plus relationnel (l'utilisateur aime son smartphone, il est un peu addict et n'aime pas qu'on lui prenne la tête.
De l'image de la vidéo.
Pas de push, pas de pub, c'est le user qui doit revenir et pas l'inverse.
On voit bien par là qu'il faut un contenu adapté; renvoyer une image de gros site ou de pro ne sert á rien; autant faire avec du neuf et de l'adapté.
A partir de ce constat ne vaut-il pas mieux (à mon avis) faire une version supplémentaire. Mélanger les deux pourquoi pas, mais je ne crois pas que ce soit la meilleure solution, il ne faut pas oublier que la première vocation du smartphone c'est quand même le téléphone, les messages, l'image, la vidéo, le jeu. Pour beaucoup de gens c'est une sorte de doudou là dans ma poche, je le sors je le rentre; rien à voir avec de la com traditionnel (pour certains pros peut être) mais pas pour le commun des mortels.
Je vais lire avec beaucoup d'attention naturellement le lien que tu as donné sur la détection, mais j'espère quand même trouver une solution pour envoyer dans un gabarit de CMSms du contenu vers mobile ou desktop.
Ce qui est déjà super et pour ceusses qui penseraient que nous sommes un peu hors sujet c'est que nous parlons de l'intégration des contenus (mobile) en conjonction avec CMSms. A ce propos j'ai une question toute bête au sujet des blocs de contenu (pas globaux)
/*--------------------------------------------------------------------*/
Code :
{content block=bloc2 label="mon_bloc_deux"} et de {content}
//Comment éviter le duplicate content ?
// en assignant une nouvelle valeur à {content assign=my_content}et à {content block=bloc2 label="mon_bloc_deux" assign=bloc2}
//et ensuite on les utilisent comme cela ?
{bloc2} et {my_content}

Merci encore pour vos réponses
Oups,je profite de ma petite erreur de fenêtre pour rajouter un mot sur l'excellent article) proposé en lien par Exacore.
Qui nous donne un peu raison à tous les deux et je commence à être persuadé que la meilleure solution effectivement dans mon cas est de proposer deux variantes une mobile une desktop avec lien intelligent entre les deux.
oui, bon article, bien dans le ton!
J'en extrait ici la quintessence :
letrainde13h37 a écrit :la solution est entièrement dépendante de vos contraintes budgétaires ou/et temporelles, mais rappelez-vous une chose : il n’est pas toujours constructif de vouloir tout contrôler sur le Web, et face à tant d’adversité il s’avère même bien souvent que le lâcher-prise reste l’attitude la plus constructive à long terme.
heu, pour répondre à ta question isa46, si je l'ai bien comprise (car je n'en suis pas sûr):
Code :
{content block=bloc2 label="mon_bloc_deux"} ... {content}
Si ils ne sont pas dans une variable, ils apparaissent là où tu les a placés avec chacun leur propre contenu.
Il n'y a pas de risque de duplicate {content} car tu as nommé le premier bloc="bloc2".
Salut Jissey,

En fait c'était surtout par rapport à cela. (On revient au début là)
http://www.i-do-this.com/blog/14/Make-y%...bile-ready
Dans le gabarit il a deux fois content, et Goran conseille de remplacer le premier par (content block="mobile"}
mais en fait cela affiche (duplicate content)
Alors ensuite il disait de remplacer le (process data) par (content assign=my_content)
..... si tu veux bien lire par toi-même cela évitera une explication trop longue est sûrement vaseuse de ma part.

Mais bon, cela date de 2010/2011 depuis il conseille le plugin, (mobiledetect ) sans revenir sur l'excellent article
c'est quand même intéressant; la doc est un peu légère.

A+
Salut,
j'ai lu l'article et effectivement, il y a une erreur avec {content}.
On ne peux pas le mettre plus d'une fois par gabarit, ou alors, il faut créer une second block comme il le dit tout à la fin (ce qui te permettrait de mettre un contenu plus synthétique pour les mobiles).
Pour faire appel au contenu plus d'une fois dans le gabarit, il faut le mettre dans une variable soit avec
Code :
{capture assign="contenu"}{content}{/capture}
soir directement avec
Code :
{content assign="contenu"}
et ensuite appeler la variable autant de fois que l'on veut :
Code :
{$contenu}
Avec ou sans process_pagedata, ça devrait marcher maintenant.
Autre petite optimisation à faire : il appelle sa balise {mobile} et fait un capture inutile :
Code :
{mobile}{capture assign='mobiletemp'}{$mobile_detect}{/capture}
cela peut être avantageusement remplacer par :
Code :
{mobile}
tout simplement et ensuite, il suffit de tester la variable $mobile_detect qui a été positionnée dans l'udt mobile:
Code :
{if $mobile_detect}
A noter qu'il nous met une seconde variable $mobile_none dont je ne comprends pas bien l'utilité n'ayant pas épluché son code et dont il ne se sert pas dans son exemple.

Voilà voilà...
A+
en relisant ton message :
es-tu sûr que en mettant {content} et {content block="mobile"} tu obtiens une erreur de duplicate content???
Si c'est le cas, vérifie bien ton gabarit, tu as une balise {content} qui traîne...
Merci de m'avoir relancé Jissey,

Bon©a marche (en gros) sauf ipad
je m'étais embrouillé avec cette histoire de bloc de contenu mais en mettant
(..++++++..{content block='Mobile'}------++++++---------- ) dans la première condition c'est ok, j'ai laissé le script de début
/*----------------------------------------------*/
Par contre je me pose la question (après le else)
comment récupérer la feuille de style de mon template desktop

Il faut que je fasse un link rel aussi en copiant (toutes les feuilles), y'a moyen de faire autrement ou pas ???

si feuille de style(extérieures) plus besoin de (----{cms_stylesheet}---- ) ??
si ce sont des feuilles externes, tu doit faire les balises link.
Sinon, tu as une feuille mobile et une feuille desktop :
Code :
{if $mobile_detect}
{cms_stylesheet name='mobile'}
<link rel="apple-touch-icon" href="path to your mobile icon for iphone" />
<meta name="viewport" content="width=device-width; initial-scale=1.0; maximum-scale=1.0;" />
{else}
{cms_stylesheet name='desktop'}
{/if}
Ok, donc je mets le nom de la feuille de style de mon layout_desktop
en même temps je vérifierai si c'est possible pour plusieurs

Autrement, en prenant l'air je me suis aper©u que j'aurais pu les lier au gabarit (peut être)


A+
oui, tu peux les lier au gabarit aussi.
Si tu lies au gabarit, mobile et desktop, ça ne changera rien si tu conserves la méthode précitée.
Si tu uilises la balise {stylesheet} sans autre précision, toutes les feuilles de styles liées seront actives.
Mais je pensais que tu connaissais déjà tout ça non?
Re,

Je capte les deux versions
j'ai mis
Code :
{cms_stylesheet name='Layout: Left sidebar + 1 column'}
{cms_stylesheet name='Navigation: Simple - Vertical'}
pour la version mobile pas de soucis a priori tout fonctionne bien
Mais le souci est dans la version desktop, j'ai fait un test en incluant le gabarit simple navigation une colonne
il s'affiche (presque) correctement mais c'est la navigation dans les pages qui ne fonctionne pas tous les
Code :
<h1>{cms_selflink dir="start" text="$sitename"}</h1>
       et
{cms_selflink dir="start" rellink=1}
{cms_selflink dir="prev" rellink=1}
{cms_selflink dir="next" rellink=1}
L'url s'affiche, mais impossible de naviguer dans les pages.
y'a aussi LOADING qui s'AFFICHE EN BAS DE LA PAGE sous le footer et ensuite cela m'affiche une deuxième fois le contenu de la page.

Bon c'est déjà mieux qu'avant car la détection fonctionne.
J'ai réarrangé pas mal de choses dans le gabarit mais là je suis bloqué.
Si tu veux, je pourrais mettre le gabarit en entier en ligne.

A+
isa46 a écrit :Si tu veux, je pourrais mettre le gabarit en entier en ligne.
oui mais dans un nouveau POST car là, on est sorti du sujet initial.
OK,
désolé de ne pas avoir répondu plus tôt
décès parent proche

On peut donc fermer, je tâcherai de revenir prochainement.

A+