balcms
1.0.0
BALCMS est un CMS de framework Zend et de doctrine ORM.
BALCMS est différent des autres CMS car nous pouvons l'étendre directement en ajoutant simplement un nouveau module - ou même en modifiant simplement le CMS directement (car le CMS n'est qu'un module et une série de dépendances). Aucun autre CMS que je connais ne permet réellement aux développeurs d'étendre le CMS si facilement et pourtant directement, vous êtes généralement verrouillé dans un cadre de plugin spécifique et limité - qui suce vraiment des balles si vous essayez de créer un CMS évolutif et extensible pour les applications personnalisées. En tant que tel, si vous n'aimez pas quelque chose sur Balcms ou si vous avez besoin d'ajouter de nouvelles fonctionnalités, vous pouvez y entrer directement et le faire! Considérez-le davantage comme une fondation plutôt que comme un verrouillage. C'est libérateur! BALCMS est également un logiciel hautement opposé, il suit les meilleures pratiques religieusement.
Balcms dépend fortement de la ligne de commande. Si vous êtes sur une plate-forme Unix / Mac / Linux, vous trouverez l'installation et l'utilisation assez simples. Si vous êtes sur une plate-forme Windows, vous pouvez faire face à une courbe d'apprentissage (et nécessiter d'exécuter des commandes via le terminal cygwin) - nous vous suggérons d'obtenir un Mac.
Il n'y aura jamais de GUI frontal pour remplacer la dépendance à la ligne de commande, car nous considérons cette dépendance comme justifiée pour être une meilleure pratique. Une fois que vous vous êtes familiarisé, vous passez. Maintenant, c'est stimulant.
Pour Windows, vous devrez installer:
Pour Unix / Mac / Linux, vous devrez installer:
Ces installations vous fourniront les exigences suivantes:
Premièrement, nous devrons nous assurer que votre environnement est correctement configuré. Pour cette course ./cli check-env . S'il ne renvoie aucun message d'erreur, vous pouvez continuer. Si c'est le cas, veuillez s'occuper des messages. If you get the message saying that your git installation is not configured, then the easiest way to configure it is to setup a new free account on GitHub, create a new repository with them, follow their instructions on using and setting up the repository - once done your git installation will have been configured, so run ./cli check-env again and make sure that there is nothing else it finds, if it doesn't find anything, then woohoo and we can now proceed to installing Balcms.
Exécutez les commandes suivantes:
mkdir mywebsite
cd mywebsite
curl -OL http://github.com/balupton/balcms/raw/master/cli
./cli birth
Explication: Ce que nous faisons ici est de créer notre nouveau répertoire de site Web (dossier), puis de récupérer l'interface de ligne de commande de notre application. Ayant ce fichier, nous pouvons alors exécuter
./cli birth. La commande./cli birthest en fait composée de trois autres commandes importantes de vue qui sont:
./cli init-newqui initialise notre référentiel local (en tant que nouveau référentiel) et saisit le cœur du CMS./cli configurequi récupère les dépendances et les exigences du CMS et configure la structure du répertoire./cli installqui installe la base de données du CMS, ajuste les autorisations et exécute tous les travaux CRON.
Nous utiliserons ces commandes et similaires plus tard.
Pendant que cela s'exécute, votre site Web aura besoin de son propre référentiel GIT public ou privé. Vous pouvez en créer un sur github (bien que si vous souhaitez un privé, vous aurez besoin d'un compte payant), ou vous pouvez trouver un autre hôte privé Git.
Une fois que ces commandes ont été exécutées et que votre référentiel git distant est configuré. Nous voulons associer notre référentiel local au référentiel distant. Nous le faisons en copiant l'URL de lecture + d'écriture de notre référentiel distant, il devrait ressembler à ce [email protected]:balupton/balcms.git . Avec cela, nous exécuterons les commandes suivantes:
git remote add origin {your git repos read/write url} ; make deploy
Explication: La deuxième commande ici
./cli deployenverra nos modifications de notre branche de développement à notre branche stable, puis de la branche stable à la branchemaster. Enfin, il enverra ensuite toutes ces modifications à notre référentiel distant.
Nous voulons envoyer nos modifications au référentiel distant car nous pouvons déployer sur notre serveur distant (où notre site Web sera réellement hébergé et accessible). D'autres avantages sont également dans le cas où notre environnement de développement s'écrase, nous aurons une sauvegarde à distance. Le dernier avantage et peut-être le meilleur, c'est que si nous travaillons avec d'autres personnes, cela nous permet de collaborer tous de manière transparente ensemble.
Une fois tout cela fait, vous pourrez maintenant visiter votre nouveau site Web Balcms. Permet donc de naviguer vers notre Host local et le répertoire dans lequel nous l'avons installé (par exemple http://localhost/sites/mywebsite ).
Pour administrer votre nouveau site Web, vous irez l'emplacement admin sur votre site Web (par exemple http://localhost/sites/mywebsite/admin ). Le nom d'utilisateur par défaut est admin et le mot de passe est random - ceux-ci sont spécifiés dans l' application/data/fixtures/data.yml , ou vous pouvez les modifier à l'aide de la zone d'administration des utilisateurs.
La structure des BALCMS est basée sur la structure du framework Zend modulaire standard avec des extensions supplémentaires pour une configuration et une localisation plus faciles, avec le support pour le thème, les téléchargements de médias, le redimensionnement de l'image hors de la boîte.
Jetons donc un coup d'œil à la structure:
.gitignore - Used to tell Git about the files that we do not want committed to our repository (e.g. cache files)
.htaccess - Used to tell Apache about how requests should be handled
application/
config/
data/
cache/
database/ - Contains our SQLite Databases
dump/
fixtures/ - Contains our Initial Database Data
logs/
schema/ - Contains our Database Structure
layouts/
models/ - Contains the Models we actually use, these inherit from the models in the following sub-directories
Bal/ - Core models included by the BalPHP Library
Balcms/ - Core models used by BalCMS (these typically inherit the Bal models)
Base/ - Autogenerated by Doctrine ORM
modules/
balcms/
config/ - Our module specific Configuration
controllers/ - Our module specific Business Logic
BackController.php - For our Administration/Back Area
FeedController.php - For our News/RSS/Atom/Subscription Feeds
FrontController.php - For our Public/Front Area
views/ - Our module specific View Logic
helpers/ - Contains our Standard Content Widgets (used within our posts)
scripts/ - Contains our View Scripts
default/ - Contains our Default/Base Modules (used for Error Handling)
cli - BalCMS's Command Line Interface
common/ - Used to contain our submodules/requirements/dependencies used by BalCMS (e.g. zend framework)
config.php
il8n/ - Contains our Localisation/Language files.
index.php
public/
images/
media/
cache/ - Used by the inbuilt bundlers (View Helpers: HeadScriptBundler, HeadLinkBundler)
scripts/
styles/
deleted/ - Where deleted files go (if we don't hard delete them)
image.php - Handles on-the-fly image resizing
images/ - Where the generated/compressed/resized images go
invoices/ - Used for our invoicing functionality (not documented)
uploads/ - Where user uploads go
scripts/
styles/
themes/ - Where our applications themes go, if you want to customise the look and feel of the application, this is where it's at.
albeo/ - The default theme. Creamy green.
balcms/ - The administration theme.
titan - A creamy brown theme.
README.md - This readme that you're reading right now.
robots.txt - What to tell Search Engines. Read up on google.
scripts/ - Contains scripts used by our CLI to perform specific actions
tests/ - Unit tests for our application.
Si l'un des éléments ci-dessus était déroutant, veuillez référencer les articles suivants:
Balcms a des fichiers de configuration dans les emplacements suivants:
config.php - Used detect and set our environment (i.e. development, staging or production).
application/
config/
application.yml - Used to specify the configuration for our environments.
core.yml - Used to specify the paths that our environments will use.
nav.yml - Used to specify navigation items used in our CMS.
routes.yml - Used to specify how requests are directed in our CMS.
default/ - Contains the files that the above config files inherit their config from. Never edit the files in this directory (as they will be overwritten when you do an upgrade).
data/
fixtures/
data.yml - Used to specify the default data that is loaded into our database
schema/
schema.yml - Used to specify our database structure (our models)
Les fichiers qui vous intéressent sont principalement config.php et application.yml , parfois nav.yml . À moins que vous ne prévoyiez d'étendre les BALCMS pour ajouter des fonctionnalités personnalisées, vous n'aurez jamais besoin de toucher les autres fichiers de configuration.
Les fichiers de documentation incluent soit la documentation en ligne (les documents à l'intérieur), soit ils sont explicatifs. Le processus de modification de l'éditeur que nous aimerions utiliser pour notre contenu irait comme ceci:
application/config/default/application.yml , recherchez la propriété appropriée - Dans ce cas, il est editor.code .application/config/application.yml - de sorte que nous modifions notre fichier de configuration, pas le par défaut../cli clean-config pour nous assurer que la modification est appliquée - nous essayons de modifier automatiquement les modifications, mais la pédantine peut parfois être utile. Pour commettre vos modifications, vous voudrez exécuter les commandes suivantes:
cd mywebsite
git status
git add -u
git status
git add {the untracked files reported by the git status}
git commit -m "My Changes... {this is your message}" (note: this commits your changes)
git push origin --all (note: this sends your changes to the remote repository)
Explication: Ce que le
git statusfait nous montre les modifications que nous avons apportées, nous l'utilisons la première fois pour vérifier les modifications apportées (afin que nous puissions dire si nous voulons apporter ces modifications). Nous pouvons réellement voir les changements de détail en exécutantgit diff. Nous ajoutons ensuite les fichiers que nous voulons à la validation suivante en utilisantgit add. Dans l'exemple ci-dessus, nous utilisonsgit add -ucar cela nous sauvera beaucoup de frappe, il ajoute automatiquement les modifications à tous les fichiers suivis (fichiers que le référentiel GIT connaît déjà). Après avoir exécuté legit add -u.
La configuration du serveur en direct peut être effectuée par l'une des deux manières suivantes.
Option recommandée: SSH + GIT. Cette option est purement géniale, elle est rapide, simple, facile à utiliser et nous permet de modifier des fichiers sur le serveur distant. Bien que peu de serveurs prennent en charge SSH et GIT (votre serveur a besoin des deux) - mais les avantages sont massifs. Nous vous recommandons d'héberger avec Mediatemple car ils sont également purs géniaux, ils soutiennent donc cette fonctionnalité impressionnante pure (leurs plans sont également extrêmement bon marché pour ce qu'ils offrent, le support est fantastique, et leur système est extrêmement flexible et personnalisable pour tous vos besoins) - Encore une fois, ils sont purs géniaux. Si votre serveur ne prend pas en charge SSH + GIT, alors c'est bien, car nous pouvons utiliser l'option de secours. Couvrons comment nous allons faire cela.
Vous voudrez vous connecter à votre serveur via SSH (reportez-vous au manuel de votre serveur pour savoir comment procéder).
Une fois terminé, vous voudrez alors cd dans votre répertoire de sites Web (par exemple public_html ).
Ce répertoire doit être vide car nous faisons une installation propre (si elle n'est pas vide, sauvegardez-la et vide). Maintenant qu'il est vide, nous voulons exécuter les commandes suivantes:
curl -OL http://github.com/balupton/balcms/raw/master/cli
git init
git remote add origin {your git repos read/write url}
./cli init-existing; ./cli configure; ./cli install
Explication: Ces commandes devraient ressembler assez à nos commandes d'installation locales, bien qu'il existe des différences. Nous commençons par récupérer notre CLI comme d'habitude, bien que maintenant nous appelons ensuite
git init, cela indique à notre environnement de traiter le répertoire actuel comme un référentiel GIT. Nous procédons ensuite à associer notre répertoire au référentiel distant. Enfin, nous exécutons les commandes./cli init-existing; ./cli configure; ./cli install. C'est la même chose qu'auparavant, mais cette fois, nous exécutons./cli init-existing, au lieu de./cli init-new- car nous avons maintenant un référentiel GIT existant avec lequel nous travaillons (donc nous le récupérons), alors qu'avant, nous avons dû créer le référentiel GIT à partir de zéro (ses branches, structure, etc.).
Vous avez tous terminé maintenant, votre site Web est maintenant en direct.
Option de secours: utilisez un système de déploiement tiers. Cette option consiste à enregistrer un compte auprès d'un tiers, à configurer votre référentiel GIT avec eux, à leur donner les détails de votre serveur et à spécifier les paramètres de déploiement. C'est bien, mais peut être coûteux lorsque vous déployez sur plusieurs sites et ne vous permet pas de modifier des fichiers sur votre site en direct (vous devez plutôt apporter la modification sur votre site local, puis déployer). Il peut également prendre un temps équitable pour déployer des modifications (de quelques minutes à quelques heures). Si vous empruntez cette voie, nous recommandons DeployHQ - leur système fonctionne très bien et ils ont des prix abordables. Reportez-vous à la documentation de votre système choisi pour utiliser cette option.
Option idiote: transférer manuellement les fichiers sur FTP. La raison pour laquelle cette option est idiote, c'est qu'elle hérite des problèmes de ne pas utiliser de contrôle de version - vous vous retrouvez rapidement avec des écarts entre votre serveur en direct et votre copie locale, provoquant des cauchemars d'incohérence et de débogage et de maintenance. Veuillez ne pas utiliser cette option, sauf si vous êtes masochiste. Nous ne couvrirons pas cette option.
Remarque: Avant de se déployer sur le site en direct, vous devrez avoir ajouté un environnement de production à votre fichier config.php et configurer votre base de données pour l'environnement de production dans le fichier application/config/application.yml .
Une fois que nous sommes satisfaits de notre copie locale et que nous voulons le déployer sur le site en direct, nous devons simplement exécuter la commande déjà familière ./cli deploy dans notre répertoire de sites Web.
Une fois que nous aurons déployé nos modifications à notre référentiel GIT distant, nous voulons ensuite retirer ces modifications sur notre serveur en direct. Cela dépend de l'option que nous avons choisie.
Utilisation de l'option Fallback (Système tiers): Avec cette option, le déploiement de notre référentiel GIT distant à notre serveur en direct peut se produire automatiquement, ou nous devions nous connecter à leur système et déployer manuellement les modifications et attendre très longtemps.
Utilisation de l'option recommandée (SSH + GIT): nous voulons SSH dans notre serveur Web et notre CD dans notre répertoire de sites en direct (comme nous l'avons fait lorsque nous configurons le référentiel GIT). Une fois, il voudra simplement exécuter la commande ./cli update . Cela rapportera toutes les modifications récentes et garantira que notre configuration est à jour.
Pour mettre à niveau votre application vers la dernière version des Balcms, vous aurez juste besoin d'exécuter ./cli upgrade dans le répertoire de votre application.
Explication: Ce que cela fera, c'est récupérer la dernière version des Balcms dans la branche Balcms et la fusionner dans notre branche de développement.
Si vous avez des conflits, vous pouvez utiliser git mergetool pour les régler.
Une fois que tous les conflits sont résolus et que la mise à niveau a réussi, vous voudrez exécuter ./cli configure pour mettre à jour tous les sous-modules / dépendances / exigences que nous utilisons.
Tout d'abord, merci d'avoir choisi ce logiciel pour votre prochain projet commercial ou même open-source.
Si vous souhaitez redonner de la valeur à ceux qui derrière ce logiciel, tout comme ils vous ont donné de la valeur, vous pouvez apporter des contributions de la manière suivante:
Codage heureux :-)
