Créer un site web pour un photographe (trad auto)

[Nota bene, ceci est une traduction automatique. Lisez à votre risque et péril.]

Aujourd'hui, je vais écrire sur mon projet pour faire décoller [SeeShoot.com] (http://seeshoot.com/). C'est un site Web bilingue pour me promouvoir pour des concerts photo et pour promouvoir ceux qui m'entourent. En général, je veux que ce soit un site utile.

J'avais commencé à utiliser un site Web gratuit et un logiciel libre appelé «heritage.io». J'ai trouvé cela à la fois en phase avec ma philosophie, mon approche technique et mes besoins. J'avais également utilisé Picassa et Flickr. Ces services publics sont pratiques. D'une manière ou d'une autre, ils me laissent encore réticents.

Je pars d'un site HTML vierge que j'ai écrit pour faire décoller l'idée de base. Ce site Web original est visible ici: http://www.seeshoot.com/old/. Ce site Web avait le plan du site suivant en anglais et en français avec un contenu squelettique:

  • Portfolio
  • Services
  • 3D
  • Liens
  • Contact

J'avais alors parcouru plusieurs sites Web pour un modèle à réutiliser et j'en ai trouvé un appelé «Aurius» à mon goût [1]. Le modèle Aurius a un plan du site de Portfolio, Blog, Contact, About (et Home). J'avais passé du temps à construire un portefeuille de portefeuilles sur ce modèle, mais j'ai été victime des suggestions de contenu derrière celui-ci, perdant de vue le contenu qui était important pour moi. Le modèle suggérait également beaucoup de présence sur les réseaux sociaux que je n'ai tout simplement pas pour cette activité. [1][http://templatecreme.com/list/aurelius/](http://templatecreme.com/list/aurelius/)

Eh bien, j'avais d'abord publié le site Web en anglais. J'aimais plus publier les photos d'autres photographes que les miennes. J'ai remarqué que je travaillais à la fois mes besoins sur le modèle et mon modèle sur les besoins.

J'ai fait réaliser le logo par un professionnel très compétent de fiver.com. Il s'intègre bien dans le gabarit, même si l'espace horizontal en haut semble un peu trop à mon goût.

Comme c'est souvent le cas, j'ai passé beaucoup de temps à peaufiner le CSS selon mes besoins. Le modèle contenait des images côté film, et je voulais des images carrées, etc. J'ai dû créer plus d'espace horizontal et trouver une solution pour que le lien de langue apparaisse.

Récemment, j'ai rencontré un consultant en affaires français Jean-Christophe Laleu. En échange de services, je devais l'aider à décoller une activité d'agence web, et Jean-Christophe devait m'aider avec SeeShoot.com. Je pensais que j'allais apporter le savoir-faire technologique et la perspicacité commerciale de Jean-Christophe. Il s'est avéré que Jean-Christophe m'a peut-être aidé sur le plan technologique (ce qui m'était inattendu).

Mes besoins pour seeshoot.com (certains d'entre eux doivent coïncider avec les besoins du Teatime / On the Street Mag Club) sont les suivants:

  1. Publiez des photos dans des albums
  2. Réorganiser et évaluer les photos
  3. Commentez les photos et gérez les commentaires sur les photos
  4. Gérez avec un minimum de travail
  5. Gérez avec une utilisation minimale de l'ordinateur
  6. Travail de version
  7. Intégration avec le modèle de site Web existant
  8. Gérer les utilisateurs et les groupes
  9. Gérer l'accès aux éléments

J'avais donc mis sur la table les choix technologiques suivants (exclusivement, ou en mix):

  1. DjangoCMS
  2. DotCMS
  3. Pyramide
  4. WordPress
  5. LogicalDoc
  6. MoinMoin
  7. CMS de raffinerie
  8. Ruby on Rails
  9. Patrimoine

Jean-Christophe est revenu vers moi avec la suggestion suivante:

  1. DjangoCMS
  2. CMS de raffinerie et Ruby on Rails
  3. WordPress

Mon environnement de programmation était Apache SSI (Server-Side Includes) de fichiers PHP. Il s'agit d'une technologie simple où les noms de fichiers se terminent par «.shtml». Mon objectif était de commencer modestement et d'ajouter de la technologie au besoin. Je prendrais les fichiers modèles et ajouterais des balises telles que <! - # include virtual = ”/ some / file.php? Var = val” -> dans la page .shtml et je programmerais tout ce qui est dynamique dans la page PHP incluse. L'un des avantages de cela est que Dream Weaver peut afficher de manière transparente les appels virtuels inclus.

J'ai été confronté à deux réalités techniques. Premièrement, PHP est compliqué. Par exemple, on m'a rappelé que l'inclusion de fichiers n'était pas simple (plus d'une façon d'écorcher un chat). Deuxièmement, pour que PHP soit propre, il faudrait Zend Framework (ou similaire). Zend Framework était trop onéreux pour les besoins actuels, surtout parce que je n'étais pas sûr de vouloir m'en tenir à la technologie.

Le raisonnement de Jean-Christophe était intéressant. Pyramid, technologie la plus belle et la plus raffinée de mon point de vue, était vue comme un «micro-cadre» pour Jean-Christophe. Django CMS, dans sa présentation sur son site Web, a été très impressionnant pour Jean-Christophe. Jean-Christophe a de l'expérience en Raffinerie, et aimerait peut-être l'utiliser dans ses propres projets à venir. WordPress est un standard.

Je voulais terminer la traduction de SeeShoot.com en français, et j'ai été confronté à la question inattendue de l'architecture locale du développement de la partie multilingue du site Web de manière SÈCHE (ne vous répétez pas).

Dans ma discussion avec Jean-Christophe, l'option la plus viable me semble Django: le Django Project original - «pour les perfectionnistes avec des délais» - et non Django CMS. Django CMS est déjà un framework au dessus d'un framework, et cela ne me rassure pas. Python est toujours un langage élégant. Django a enduré l'épreuve du temps. Je connais aussi une très bonne agence web française qui fait Django dont le nom m'échappe en ce moment. Cela me semble être un ensemble robuste et modulaire de bibliothèques que je peux utiliser.

Même si nous avons trouvé la solution parfaite sur un point de vue à moyen terme, le pire ennemi auquel je pouvais faire face en ce moment était de changer trop rapidement les solutions technologiques. Alors, à contrecœur, j'ai décidé d'emprunter la voie de la finition de ce que j'avais commencé avant de me lancer dans la nouvelle technologie. J'ai besoin d'un site Web en cours de production avant de travailler sur un nouveau.

Voici la solution que j'ai trouvée:

  1. chaque langue avait son propre sous-dossier (en et fr)
  2. le plan du site est le même dans chaque sous-dossier
  3. les ressources communes (images et photos non localisées) se trouvent dans les dossiers racine
  4. chaque fichier .shtml inclut la version / en / ou / fr / du fichier _header.php en passant une variable GET pour la section courante avec par exemple la page <! - # include virtual = ”/ en / _header.php? = blog »->
  5. le fichier _header.php fait la mise en page HTML, inclut un fichier /include/classes.php avec les classes Menu et MenuItem, et instancie un Menu avec la langue locale spécifique dans une variable $ menu
  6. _header.php utilise l'objet $ menu.

Eh bien, à mi-chemin du développement, j'avais peur de programmer quelque chose que je ne garderais pas, même si cela semblait assez élégant. Le résultat est que je n'ai pas pris soin de le documenter. Ça marche.

La mise en place de l'infrastructure multilingue m'a incité à la traduire. SeeShoot maintenant en français et en anglais.

De retour aux affaires (besoins), mon objectif est d'obtenir un concert photo pour cette nouvelle année, et SeeShoot.com n'est pas encore fait pour m'aider à cette fin. Curieusement, l'ancien site Web était plus utile dans ce domaine. Il semble que j'ai fait un pas en arrière. Pour compliquer encore plus les choses, il semble que l'ancien portefeuille ne soit plus accessible. Voici les actions potentielles:

  1. transposer l'ancien plan du site sur le nouveau site Web
  2. transposer l'ancien contenu Web sur un nouveau site Web
  3. trouver et republier l'ancien portfolio
  4. développer un nouveau portefeuille
  5. publier une note visible avec la demande d'un concert pour un événement du Nouvel An
  6. publier une page pour la prospection des événements du Nouvel An
  7. réfléchissez à quelque chose du meilleur de l'ancien et du meilleur du nouveau
  8. passer au projet Django pour une nouvelle version du site web

Et cela m'amène à aujourd'hui. Il existe deux catégories de base d'effort: maintenir l'ancien site Web et développer la nouvelle technologie sous-jacente. Si j'ai bien appris de la mise à jour de la version précédente de ce site Web, j'irai de l'avant tout en maintenant mieux les bonnes parties de ce site Web seeshoot.com actuel. En ce qui concerne ma situation actuelle, je suppose que je vais réorganiser à vue le nouveau site Web avec une partie de l'ancien contenu et mettre en place un portefeuille d'événements et de portraits (avec une vidéo si j'ai le temps et les efforts).