Local development - Githubissues

raffaelj / cpmp-lib-skeleton

Skeleton to use CpMultiplane and Cockpit CMS as libraries with a clean root directory

MIT License

2 stars 1 forks source link

Local development #3

Open Raruto opened 3 years ago

Raruto commented 3 years ago

Hi Raffael,

I'm having some troubles in trying to start a simple demo server (I can't figure out if it's a problem related to my local config or if it's just a bug), I hope I don't bother you too much...

Here are my steps:

# apache folder
cd D:/htdocs/

# create project folder
mkdir multiplane
cd multiplane

# initialize project structure
composer create-project raffaelj/cpmp-lib-skeleton .

# create admin user
php ./mp account/create --user admin --password admin --email admin@example.com

# run quickstart routine
php ./mp multiplane/quickstart --template basic
php ./mp multiplane/create-dummy-data

Until here no strange errors in console, so after that I open http://localhost/multiplane/ and i got the following error:

This site doesn't exist.

The login link at the bottom of this page points to the following url: http://localhost/login/

These are the user-defined constants for http://localhost/multiplane/:

// index.php

// bootstrap cockpit or CpMultiplane
require(__DIR__.'/bootstrap.php');
echo '<pre>' . print_r( get_defined_constants(true)['user'], true ) . '</pre>';

Array
(
    [CPMP_COCKPIT_PATH] => /lib/cockpit
    [COCKPIT_DIR] => D:/htdocs/multiplane/lib/cockpit
    [MP_ADMINFOLDER] => cockpit
    [COCKPIT_ENV_ROOT] => D:/htdocs/multiplane/cpdata
    [MP_ENV_ROOT] => D:/htdocs/multiplane
    [MP_BASE_URL] => 
    [COCKPIT_CLI] => 
    [MP_COCKPIT_ADMIN_ROUTE] => /multiplane/
    [COCKPIT_ADMIN] => 
    [MP_DIR] => D:/htdocs/multiplane/lib/CpMultiplane
    [MP_DOCS_ROOT] => D:/htdocs
    [MP_ENV_URL] => D:/htdocs/multiplane
    [MP_CONFIG_DIR] => D:/htdocs/multiplane/config
    [MP_CONFIG_PATH] => D:/htdocs/multiplane/config/config.php
    [MP_SELF_EXPORT] => 
    [COCKPIT_SITE_DIR] => D:/htdocs/multiplane
    [COCKPIT_START_TIME] => 1606666331.2246
    [COCKPIT_DOCS_ROOT] => D:/htdocs
    [COCKPIT_BASE_URL] => /multiplane/lib/cockpit
    [COCKPIT_API_REQUEST] => 0
    [COCKPIT_CONFIG_DIR] => D:/htdocs/multiplane/cpdata/config
    [COCKPIT_BASE_ROUTE] => /multiplane/lib/cockpit
    [COCKPIT_STORAGE_FOLDER] => D:/htdocs/multiplane/cpdata/storage
    [COCKPIT_ADMIN_CP] => 0
    [COCKPIT_PUBLIC_STORAGE_FOLDER] => D:/htdocs/multiplane/cpdata/storage
    [COCKPIT_CONFIG_PATH] => D:/htdocs/multiplane/cpdata/config/config.php
)

and this is the folder structure:

# tree -L 2 -a
.
├── bootstrap.php
├── composer.json
├── composer.lock
├── config
├── cp
├── cpdata
│   ├── addons
│   ├── config
│   └── storage
├── defines.php
├── docker-compose.yml
├── .env.dist
├── .gitignore
├── .htaccess
├── .htaccess.dist
├── index.php
├── lib
│   ├── cockpit
│   ├── CpMultiplane
│   └── vendor
├── LICENSE
├── mp
└── README.md

# tree -apfiL 2
.
[-rwxrwxrwx]  ./bootstrap.php
[-rwxrwxrwx]  ./composer.json
[-rwxrwxrwx]  ./composer.lock
[drwxrwxrwx]  ./config
[-rwxrwxrwx]  ./cp
[drwxrwxrwx]  ./cpdata
[drwxrwxrwx]  ./cpdata/addons
[drwxrwxrwx]  ./cpdata/config
[drwxrwxrwx]  ./cpdata/storage
[-rwxrwxrwx]  ./defines.php
[-rwxrwxrwx]  ./docker-compose.yml
[-rwxrwxrwx]  ./.env.dist
[-rwxrwxrwx]  ./.gitignore
[-rwxrwxrwx]  ./.htaccess
[-rwxrwxrwx]  ./.htaccess.dist
[-rwxrwxrwx]  ./index.php
[drwxrwxrwx]  ./lib
[drwxrwxrwx]  ./lib/cockpit
[drwxrwxrwx]  ./lib/CpMultiplane
[drwxrwxrwx]  ./lib/vendor
[-rwxrwxrwx]  ./LICENSE
[-rwxrwxrwx]  ./mp
[-rwxrwxrwx]  ./README.md

Happy thoughts, Raruto

raffaelj commented 3 years ago

It's a while ago that I tested CpMultiplane on a Windows host or in a subfolder and I never tested this skeleton on a Windows host. Since I moved from Windows with Xampp to openSUSE with Docker, I don't have these subfolder problems anymore and I often forget to test these cases.

But from your output I see, that MP_BASE_URL should be /multiplane (eventually with slash at the end).

Does it work if you add define('MP_BASE_URL', '/multiplane'); in defines.php?

edit: Also MP_COCKPIT_ADMIN_ROUTE should not contain /multiplane. But that should be solved with the MP_BASE_URL fix from above.

Raruto commented 3 years ago

Thank you for the tip,

with the code of pull https://github.com/raffaelj/cpmp-lib-skeleton/pull/4 I managed to get to the following page: http://localhost/multiplane/cockpit/

mpbasic

in the next days I will try to check if the i18n works.

It's a while ago that I tested CpMultiplane on a Windows host or in a subfolder and I never tested this skeleton on a Windows host. Since I moved from Windows with Xampp to openSUSE with Docker, I don't have these subfolder problems anymore and I often forget to test these cases.

I had also done some successful tests with docker (I have read a lot on the subject, but I'm not very well versed with it, eg. it is still not clear to me how the whole development cycle could work).

Have a nice day, Raruto

Raruto commented 3 years ago

If it helps, this is my current configuration within the settings page: http://localhost/cpmp-lib-skeleton/cockpit/settings/edit/true

settings-edit

and this is the code snippets used to debug:

// bootstrap.php

...

/**
 * View the debug info on top of the layout
 *
 * @link https://zeraton.gitlab.io/cockpit-docs/tutorials/advanced/debugging-cockpit.html
 */
$cockpit->on('app.layout.contentbefore', function() {

    $defined_costants = get_defined_constants(true)['user'];
    ksort($defined_costants);

    $vars = [
        'app_important_routes' => [
            'route' => $this['route'],
            'base_url' => $this['base_url'],
            'base_route' => $this['base_route'],
            'base_host' => $this['base_host'],
            'base_port' => $this['base_port'],
            'docs_root' => $this['docs_root'],
            'site_url' => $this['site_url'],
        ],
        'DOCUMENT_ROOT' => $_SERVER['DOCUMENT_ROOT'],
        'cockpit_DIR' => dirname(dirname(__DIR__)), // may differ from DOCUMENT_ROOT (symlinks)
        'user_constants' => $defined_costants,
        'app_paths' => $this['paths'],
        // 'SERVER' => $_SERVER,
        // 'app_config' => $this->config, // config.yaml + app defaults
        // 'app' => $this, // the whole app, needs a few seconds to load/print
    ];
    echo '<pre>' . print_r($vars, true) . '</pre>';
});

output log:

raffaelj commented 3 years ago

Thank you for your precise issues with debug output and screenshots. This helps a lot.

I had also done some successful tests with docker (I have read a lot on the subject, but I'm not very well versed with it, eg. it is still not clear to me how the whole development cycle could work).

Same here... I spend days with reading the docs, blog posts and threads on stackoverflow and I discovered only the basics. I don't use it for production, but for local development. Now I can switch PHP or MySQL versions with changing one line in docker-compose.yml and I don't have to pollute my system if I need a ruby environment (jekyll) every few months.

and this is the code snippets used to debug: [...] @link https://zeraton.gitlab.io/cockpit-docs/tutorials/advanced/debugging-cockpit.html

It's funny to see my own code from two years ago cited here :smile:

Raruto commented 3 years ago

Thank you for your kindness,

although, I still haven't found enough time to try cockpit / multiplane properly.. 🤦

I spend days with reading the docs, blog posts and threads on stackoverflow and I discovered only the basics. I don't use it for production, but for local development.

If it can help, I just found this fairly new and simple service that could be used as a deployment / hosting platform for docker containers (out of curiosity, given this warning, what would you recommend to edit or remove for using it in a production environment?).

In the next few days I will try again with docker (useful link for other readers).

raffaelj commented 3 years ago

out of curiosity, given this warning, what would you recommend to edit or remove for using it in a production environment?

Run the container as apache user. Than you don't need these lines anymore:

    user: ${DOCKER_USER:-1000}:${DOCKER_GROUP:-1000}
    sysctls:
      - net.ipv4.ip_unprivileged_port_start=0

You could even shrink it down to these few lines:

version: "3.7"
services:
  cpmp:
    image: raffaelj/php7-apache-base
    volumes:
      - ./:/var/www/html

Also I'm not familiar enough with server security. I created the dockerfile to fit my development needs. On my local machine I don't have to care much about vulnerabilities. Than I used Github Actions to automate the image builds. So:

I don't have the time to constantly check for security updates in that image.
I might add software to the image that is meant for local tests, but not for production and the current automation overwrites the images without a version update.
I use multiple black boxes in the dev stack (Github, build automation, Dockerhub), where I don't really know, what's going on behind the scenes.
I keep losing trust in the used services. Dockerhub tempts users to use the Github API with full write access to all repositories. The Dockerhub API needs full write access to all images to update the README of a single image. I like Github, but I don't trust Microsoft. Github started to implement weird features with oauth and browser redirects to desktop apps, where a SSH keys worked fine before...

That's why I don't recommend to use my docker images in production. The docker-compose.yml files are meant for local development because of the arbitrary user usage.

I just found this fairly new and simple service that could be used as a deployment / hosting platform for docker containers

Thanks for the hint, but it looks like the next black box without GDPR compliance. So I'm not sure if I want to use it.

Raruto commented 3 years ago

Yes, I know what you mean..

I tried with docker and it works fine ( thanks for the detailed explanation ).

About your concerns, maybe you already know them, anyway, I suggest you take a look at following links:

https://docs.gitlab.com/ee/user/packages/container_registry/ ( as a Docker Hub alternative )
https://docs.gitlab.com/ee/ci/docker/using_docker_build.html ( as a GitHub Actions alternative )
https://about.gitlab.com/install/ ( if you have enough time resources... )
https://about.gitlab.com/privacy/privacy-compliance/ ( if you just like the platform... )

PS Overall, don't you think it would be easier to maintain a side-by-side cockpit and multiplane installation? (instead of just forcing everything into a "single" folder)

.
├── cockpit/
│   └── .git
├── multiplane/
│   └── .git
├── .git
├── .htaccess
└── index.php

Feasibility issues aside, in this way, I think:

it would be more understandable for everyone what is part of the "cms core" and what is not (without the needing of too much additional docs?)
you could autonomously update the two repositories yourself ( without big headaches? )
would the number of subfolders decrease? ( every now and then I admit to getting lost: “who was the parent?”... )

raffaelj commented 3 years ago

Gitlab.com as also a privacy nightmare with tons of third party resources. So I'll stick with the services, I'm already familiar with until I find the time to test and maintain a self hosted Gitlab instance. Until then I try to avoid using too much features that will bind me to a specific platform (e. g. Github Projects or Github Wiki...).

Overall, don't you think it would be easier to maintain a side-by-side cockpit and multiplane installation?

There are a few problems...

Calling example.com/cockpit would open ./cockpit/index.php. I avoided this by moving it into ./lib/cockpit and by denying access to php files inside the lib folder via .htaccess.

I don't want to have sub folders in the docs root, that might match url slugs. That's why I try to have as less as possible sub folders and to keep them all configurable.

I'm still not very satisfied with the file and folder structure of CpMultiplane. This cpmp-lib repo (and updating all of my addons for composer usage) was my first step to keep the docs root clean and to be able to use multiple workflows (git, composer, folder mounts via docker) for dependencies (addons).

In the long run, I want to split CpMultiplane into some more repositories to separate themes. And I think about a structural change to merge the CpMultiplaneGUI addon with the Multiplane module to install it directly as Cockpit addon. If that's done, the structure should be much cleaner. Than, the main/base repository could only contain a few files to define the folder structure and to map the routes to the frontend/backend.

It's a grown structure and it started with the mindset of keeping CpMultiplane separated from Cockpit so the backend still works as a stand-alone application (e. g. for fast rest api usage without having to read frontend files on each request). Now they both interact with each other, so I can skip that idea... These thoughts need to ripen a bit and until then I want to contentrate on cleaning up some experimental parts and on updating the docs.

Raruto commented 3 years ago

Ok thanks, got it.

I'll stick with the services, I'm already familiar with until I find the time to test and maintain a self hosted Gitlab instance

I swear I stop spamming 😋, but maybe a self-hosted gitea instance (or codeberg.org) could be more within your reach.

Thanks again, Raruto

raffaelj commented 3 years ago

Codeberg sounds amazing. I spent the last 4 hours reading their docs and issues. So please don't stop spamming :D I'll give it a try, but not now and probably not in the next weeks...

I hope I don't bother you too much... I swear I stop spamming

It's nice to talk with you about these structural questions. To be honest, I don't know, if anyone besides me uses CpMultiplane in production and it's hard to think about all possible use and edge cases without external input. Also a lot of things become more clear and precise to me when I'm talking/writing about it instead of just having some ideas somewhere in my mind.

Raruto commented 3 years ago

It's nice to talk with you about these structural questions.

Hello again and thanks.

Overall I am convinced that this type of structure is still the most flexible and easier to understood by most (a single index.php file as entry point / router).

From the little I have learned, cockpit is already very flexible in its core structure (eg /config folder), furthermore, favoring a modular structure allows you to test one thing at a time (and subsequently disable them with ease).

Regarding to child themes, is it really worth it to keep such a convoluted structure? Overall, wouldn't it be just easier to maintain several starter repositories? From which to download plugins, routes, collections and other default template data (as it happens for many SSGs). The same reasoning could be also applied to the "basic components" of a site (navigation, sitemap, forms, search, ...).

I think that moving cockpit into a subfolder is too much "forcing". Although customizable during installation, I don't think it would be as easy to switch from a Multiplane site to "just" a Cockpit site.

To be clear, I don't want to convince you that this reasoning is any better, just take it as feedback from a casual user 😄