contentacms / contenta_jsonapi Goto Github PK

I think it would be useful to show the about US page right after the installation.

https://gist.github.com/e0ipso/efcc4e96ca2aed58e32948e4f70c2460

We want to move recipes_magazin into the profile so we can diverge the data model from ootbei.

We also want a dev dependency on features:

• Installing drupal/simple_oauth (2.0.0-rc2) Loading from cache
• Installing drupal/schemata (dev-1.x 99c723d) Cloning 99c723ddd4 from cache
• Applying patches for drupal/schemata
  https://www.drupal.org/files/issues/2870904-22.patch (https://www.drupal.org/files/issues/2870904-22.patch)
  Could not apply patch! Skipping. The error was: Cannot apply patch https://www.drupal.org/files/issues/2870904-22.patch

Allow people to filter the tutorials per topic in /help/tutorials.

Should we theme the installer maybe?

Hi. Congratulations for the awesome project of Contenta!
I installed Contenta in my desktop (Ubuntu 16.04) without problems, but installing in a Linux shared server I got this warning after "Configure site" and in all the pages (where USER is my account):

Warning: file_exists(): open_basedir restriction in effect. File(/) is not within the allowed path(s): (/home/USER/:/tmp:/usr/local/php/7.0/lib/php:./) in League\OAuth2\Server\CryptKey->__construct() (line 43 of /home/USER/app/contenta/vendor/league/oauth2-server/src/CryptKey.php).

League\OAuth2\Server\CryptKey->__construct('file://') (Line: 50)
League\OAuth2\Server\ResourceServer->__construct(Object, NULL) (Line: 42)
Drupal\simple_oauth\Server\ResourceServer->__construct(Object, Object, Object, Object) (Line: 280)
Drupal\Component\DependencyInjection\Container->createService(Array, 'simple_oauth.server.resource_server') (Line: 177)
Drupal\Component\DependencyInjection\Container->get('simple_oauth.server.resource_server', 1) (Line: 494)
Drupal\Component\DependencyInjection\Container->resolveServicesAndParameters(Array) (Line: 236)
Drupal\Component\DependencyInjection\Container->createService(Array, 'simple_oauth.authentication.simple_oauth') (Line: 177)
Drupal\Component\DependencyInjection\Container->get('simple_oauth.authentication.simple_oauth', 1) (Line: 494)
Drupal\Component\DependencyInjection\Container->resolveServicesAndParameters(Array) (Line: 329)
Drupal\Component\DependencyInjection\Container->createService(Array, 'authentication_collector') (Line: 177)
Drupal\Component\DependencyInjection\Container->get('authentication_collector') (Line: 72)
Drupal\jsonapi\Routing\Routes::create(Object) (Line: 28)
Drupal\Core\DependencyInjection\ClassResolver->getInstanceFromDefinition('\Drupal\jsonapi\Routing\Routes') (Line: 123)
Drupal\Core\Controller\ControllerResolver->createController('\Drupal\jsonapi\Routing\Routes::entryPoint') (Line: 74)
Drupal\Core\Controller\ControllerResolver->getControllerFromDefinition('\Drupal\jsonapi\Routing\Routes::entryPoint') (Line: 145)
Drupal\Core\Routing\RouteBuilder->rebuild() (Line: 83)
Drupal\Core\ProxyClass\Routing\RouteBuilder->rebuild() (Line: 1141)
drupal_flush_all_caches() (Line: 2360)
install_config_import_batch_finish(1, Array, Array, '2 min 21 sec') (Line: 414)
_batch_finished() (Line: 81)
_batch_page(Object) (Line: 642)
install_run_task(Array, Array) (Line: 550)
install_run_tasks(Array) (Line: 121)
install_drupal(Object) (Line: 44)

I don't have access to my php.ini and I cannot change "open_basedir restriction" through the server PHP options.
Any idea about how to disable this? Or is it possible to fix Contenta (as it do not happens in another Drupal distributions)?
Thanks.

To speed up the installation process it would be nice to have a build that we could leverage GitHub releases.

The idea is that for each merge to master (we should all use squashed commits), we should have a ZIP file with the result of composer-create. There is currently a task in Travis that builds the site for testing purposes. We should be able to leverage a lot of that logic to create the build asset. Then an auto-release with the build asset should be deployed by travis in GitHub.

When composer update is run, it can potentially fetch packages which are more up-to-date than what is expected for Drupal Core.

Adding "webflo/drupal-core-strict": "^8.3" to the require section of composer.json should prevent this.

See https://github.com/webflo/drupal-core-strict for more details

So when that module is removed, the personalizations are gone.

A chatbot could have one of the following opportunities:

• Create recipes via asking
• Create recipes via tracking while you actually cook something
• Provide you recipes given some recipes you liked before
• I have the following ingredients, what can I cook today

Problem

At the moment we are executing node install as part of the create-project composer command in contenta_jsonapi_demo.

If we combine that with the package.json in contenta_jsonapi we have that the Nigthwatch testing environment is installed in production mode.

Suggested solution

• Convert the dependencies in package.json to devDependencies.
• Make the create-project composer command run npm install --production. Remove the command in ScriptHandler.php that runs npm install
• Make sure the .travis deployer installs the devDependencies to run tests.

Things to discuss:

• Enable CORS support for '*' out of the box as a default.
• Allow changing the '*' for a list of allowed domains using the UI installer.
• Provide a contenta-cors-enable drush command.
  Other?

Reservoir has many great things. Let's list the features that we like from the project and vote on them if we'd like to see them in Contenta CMS.

One feature per comment, please add your own! When you add a feature add both a 👍 and a 👎 so people can vote with a single click. Please add screenshots if applicable.

ReflectionException: Class does not exist in [error]
/var/www/contentacms/web/core/lib/Drupal/Core/Installer/Form/SiteSettingsForm.php:154

Full stack trace:

-----------------------------------------------
 (2/4) Installing Contenta CMS for local usage 
-----------------------------------------------
 EXECUTING  /var/www/contentacms/bin/drush si contenta_jsonapi --db-url=sqlite://sites/default/files/.ht.sqlite --account-pass=test -y


You are about to CREATE the 'sites/default/files/.ht.sqlite' database. Do you want to continue? (y/n): y
Starting Drupal installation. This takes a while. Consider using the [ok]
--notify global option.
ReflectionException: Class  does not exist in                        [error]
/var/www/contentacms/web/core/lib/Drupal/Core/Installer/Form/SiteSettingsForm.php:154
Stack trace:
#0
/var/www/contentacms/web/core/lib/Drupal/Core/Installer/Form/SiteSettingsForm.php(154):
ReflectionClass->__construct('')
#1 [internal function]:
Drupal\Core\Installer\Form\SiteSettingsForm->validateForm(Array,
Object(Drupal\Core\Form\FormState))
#2
/var/www/contentacms/web/core/lib/Drupal/Core/Form/FormValidator.php(83):
call_user_func_array(Array, Array)
#3
/var/www/contentacms/web/core/lib/Drupal/Core/Form/FormValidator.php(270):
Drupal\Core\Form\FormValidator->executeValidateHandlers(Array,
Object(Drupal\Core\Form\FormState))
#4
/var/www/contentacms/web/core/lib/Drupal/Core/Form/FormValidator.php(119):
Drupal\Core\Form\FormValidator->doValidateForm(Array,
Object(Drupal\Core\Form\FormState), 'install_setting...')
#5 /var/www/contentacms/web/core/lib/Drupal/Core/Form/FormBuilder.php(571):
Drupal\Core\Form\FormValidator->validateForm('install_setting...',
Array, Object(Drupal\Core\Form\FormState))
#6 /var/www/contentacms/web/core/lib/Drupal/Core/Form/FormBuilder.php(481):
Drupal\Core\Form\FormBuilder->processForm('install_setting...',
Array, Object(Drupal\Core\Form\FormState))
#7 /var/www/contentacms/web/core/includes/install.core.inc(938):
Drupal\Core\Form\FormBuilder->submitForm('Drupal\\Core\\Ins...',
Object(Drupal\Core\Form\FormState))
#8 /var/www/contentacms/web/core/includes/install.core.inc(594):
install_get_form('Drupal\\Core\\Ins...', Array)
#9 /var/www/contentacms/web/core/includes/install.core.inc(550):
install_run_task(Array, Array)
#10 /var/www/contentacms/web/core/includes/install.core.inc(121):
install_run_tasks(Array)
#11 /var/www/contentacms/vendor/drush/drush/includes/drush.inc(726):
install_drupal(Object(Composer\Autoload\ClassLoader), Array)
#12 /var/www/contentacms/vendor/drush/drush/includes/drush.inc(711):
drush_call_user_func_array('install_drupal', Array)
#13
/var/www/contentacms/vendor/drush/drush/commands/core/drupal/site_install.inc(82):
drush_op('install_drupal', Object(Composer\Autoload\ClassLoader),
Array)
#14
/var/www/contentacms/vendor/drush/drush/commands/core/site_install.drush.inc(255):
drush_core_site_install_version('contenta_jsonap...', Array)
#15 /var/www/contentacms/vendor/drush/drush/includes/command.inc(422):
drush_core_site_install('contenta_jsonap...')
#16 /var/www/contentacms/vendor/drush/drush/includes/command.inc(231):
_drush_invoke_hooks(Array, Array)
#17 /var/www/contentacms/vendor/drush/drush/includes/command.inc(199):
drush_command('contenta_jsonap...')
#18
/var/www/contentacms/vendor/drush/drush/lib/Drush/Boot/BaseBoot.php(67):
drush_dispatch(Array)
#19 /var/www/contentacms/vendor/drush/drush/includes/preflight.inc(66):
Drush\Boot\BaseBoot->bootstrap_and_dispatch()
#20 /var/www/contentacms/vendor/drush/drush/drush.php(12): drush_main()
#21 {main}
 ERROR  The Drupal installer failed to install Contenta CMS.
Script scripts/development/build-contenta_jsonapi.sh handling the install-contenta event returned with error code 3
tormi@ASUS-N56VV:/var/www$ 

Currently the installer script (installer.sh) assumes everything is installed, but this might not be true.

• Check for the PHP version.
• Check for sqlite being available ...
• Composer is installed.

Just an idea, it would be nice if we would have continues testing of the installer

• Once #40 is merged
• Create a .travis.yml file
• Add a test-installer.sh file inside a tests folder
• Execute it from within travis
• Ensure that after the process we have a webserver running on :8888 and we can access the default recipes via HTTP

I understand this is a known issue.

In recipes_magazin.install there are multiple migrations that run during an installation. One of them is 'recipes_magazin__images_url', which I'm told downloads many images from the web.

The result is that without this migration, on a good day, a "rebuild" using scripts/development/build-contenta_jsonapi.sh and a warm composer cache etc. takes approximately 2 minutes, with about 15 seconds of that being the Drupal install. With that one migration added the Drupal installation takes at least an extra 6+ minutes, meaning a build takes from 7 to sometimes over 10 minutes depending on composer cache, or xdebug is enabled etc.

More of a serious problem for contributors but due to the lack of feedback also an issue for users going forward as it can appear frozen.

Following up from the routing discussion in Slack, we would like a module that prevents Drupal from using the contents of the path field for routing. The path field will provide the routes that front-end consumers use, and this prevents conflicts from trying to overlay a should-be-separate routing system on top of Drupal's routing system, without losing the benefits of the path module (i.e. pathauto integration)

The path field currently checks for conflicts in values with other path fields, this functionality should be maintained.

Here is an idea.

What if we added some tutorial content as demo content. That way when you install Contenta CMS you get a list of Tutorials on different topics:

• How to make queries against the provided content model.
• How to create content (recipe reviews) using the API.
• How to authenticate your requests.
• How to set CORS to match your domain.
• How to deal with routing.
• …

We could provide this content as web pages in Contenta (rendered with the admin theme, it's fine for now) along with the demo content. When you're done you uninstall the demo content and the tutorials are gone and you're left with the site you configured thanks to the tutorials.

With this idea we meet 2 goals:

1. Knowledge base right there.
2. Enhanced demo content and richer content model.

Following up from the routing discussion in Slack, JSON:API needs to return the value of the new path of some content when it's slug/path has been changed.

It doesn't need to return the contents of the node at the new location, just the value of the new path so a redirect can be sent to the user.

See http://humanstxt.org/

Following on from #60 (comment)

My preference would be to not show the Node View at all, since rendering on the back-end doesn't really make sense in a decoupled world, and instead have the default tab be Edit. Other tabs can then link to the front-end for that particular node. Here's an example of something in production:

I do like the JSON view like this:

I would love to see that as a separate tab for users with the developer role.

This is currently blocked by Schemata.

Some resources are exposed by default and we want to disable them using JSON API Extras.

• node--tutorial
• search_page--search_page

As we can learn from reservoir, we can totally improve the experience by providing a more focused admin UI.

• Make content modelling a first class citizen
• Make UI developers tasks a first class citizien, aka. API documentation, OAuth client, Oauth tokens etc.

After #20 lands we'll have a landing page after installation. It will be set to the About us page. However we want to have a page that is more dedicated to explain next steps after installation.

I'm thinking of the scenario … ok, I have this installed. What now?

We'll need:

• Content for the front page.
• Design for the front page (it can come later as a follow up).

Dependencies:

• Page migration so the content for the page can be just a set of CSV rows in existing files.

What do we want to have before a release?

Note: A release adds a lot of momentum, there is some magical force involved

https://www.drupal.org/u/samuelmortenson offered to get involved with an ionic native app.
That's great, as for example, the more frontends we have, the better it gets for other frontends, as we will explore the potential problems

It would be great if samuel mortenson could come up with general ideas how this native app would look like, which features it could provide etc.

We could add dropzonejs integration which massively improves the UX for uploading images.

Problem: How do we integrate this JS library using composer automatically?
One possibility is to use the concrete releases and reference them as drupal-library, see https://gist.github.com/mortenson/a5390d99013b5b8c0254081e89bb4d47#file-composer-json-L10

This allows you to not commit the libraries, while not requiring any other package managers.

Drupal core (standard profile), decided to provide as performant as possible configuration by default.

This includes

• Disabling showing of error messages
• some more

The underlying question though is: Do we want to follow the same route of having production settings by default?

See the Slack thread.

Here is a first version for the homepage design based on #22 as a starting point. Let's iterate on that.
Here is the source on Figma: https://www.figma.com/file/JPY2wxeDoDXXVrdiJCdmWMFn/Contenta?node-id=75%3A157

See Slack discussion: https://drupal.slack.com/archives/C5A70F7D1/p1495575161979991

Problem

Currently the instructions are a fulltext field, which makes it potentially problematic for frontends to render:

• Reading a fulltext is hard
• Just showing some of the steps is hard

Proposal

Split the instructions up in a list of instructions, basically a list of strings, not wysiwyg content.

Discussion

There is a lot to discuss. Results:

• You want to ensure editor experience doesn't suffer, so a single textarea should be used for the input.

contentacms.sh deletes $mytmpdir (rm -Rf $mytmpdir), but it doesn't remove it's leftovers from composer.json:

        "contenta_jsonapi": {
            "type": "path",
            "url": "/tmp/tmp.rNrutuiEsy"
        }

Tried quick install and failed:

Error: Class 'Drupal\bootstrap\Bootstrap' not found in include_once() (line 30 of /web/themes/contrib/bootstrap/bootstrap.theme).
Drush command terminated abnormally due to an unrecoverable error.   [error]
 ERROR  The Drupal installer failed to install Contenta CMS.
Script scripts/development/build-contenta_jsonapi.sh handling the install-contenta event returned with error code 3

When logging into the site using the form at /user, the browser displays an almost-empty page with just the message "Not Allowed."

This is likely due to the CORS bug described in https://www.drupal.org/node/2853201

@dawehner suggested applying: https://github.com/asm89/stack-cors/commit/6daf5757971173b79ddabbd755d59d333c278f42.patch
to fix this.

Here is a question: Where should the documentation live?

• A readme inside the contenta_jsonapi profile?
• As a separate github book, which might be able to ship with some recommendations about best practises/general design decisions?
• Maybe somewhere else?

It was brought in by a dependency on the materialize base theme (it is a bug).

Make sure:

• The bug is fixed.
• The search module is disabled.

samuel.mortenson
I’m running it :open_mouth:

[6:54 PM] 
would be cool to `composer global require` the install script

Ideas:

• Provide a composer package which includes just the installer
• Somehow produce a phar file out of the installer and let people install that one
• Maybe other ideas?

We have something going on with CircleCI and Pantheon, but it's a bit abandoned / disfunctional at the moment.

I've used the following template in many projects:

Task: #123

* [x] Ready for review
* [x] Ready for merge

... description

### Notes

... Notes-optional

### Test Instructions

Test-instructions

### QA

... Screenshots/Screencasts-optional

See https://github.com/acquia/reservoir/blob/8.x-1.x/reservoir.install#L31

Let's put a brief explanatory blurb at the top of the readme that describes what Contenta is, and what it does (and maybe why you should use it?)

It would be nice to have a role for editors as well as one role for developers.

What kind of permissions should each of those actually have?

I tried the quick installation process and it failed. Then, I tried it directly using composer and that worked correctly. Here are some details:

Environment: Linux / Debian testing

PHP:

$ php --version
PHP 7.0.19-1 (cli) (built: May 11 2017 14:04:47) ( NTS )
Copyright (c) 1997-2017 The PHP Group
Zend Engine v3.0.0, Copyright (c) 1998-2017 Zend Technologies
    with Zend OPcache v7.0.19-1, Copyright (c) 1999-2017, by Zend Technologies

Composer:

$ composer --version
Composer version 1.2.2 2016-11-03 17:43:15

It returns this error at the end of the process:

Command runserver needs a higher bootstrap level to run - you will need to invoke drush from a more functional Drupal environment to run this command.
The drush command 'runserver 127.0.0.1:8888' could not be executed. Drush was not able to start (bootstrap) the Drupal database.

It seems like the symlink to the profile is broken:

contenta_jsonapi -> /tmp/tmp.On0qzFY6Fa

The permissions of the folder seem correct:

$ ls -la
total 248
drwxr-xr-x  6 david david   4096 Jun 29 20:30 .
drwxr-xr-x  4 david david   4096 Jun 29 21:18 ..
drwxr-xr-x  2 david david   4096 Jun 29 20:30 bin
-rw-r--r--  1 david david   2209 Jun 29 20:23 composer.json
-rw-r--r--  1 david david 217122 Jun 29 20:30 composer.lock
-rw-r--r--  1 david david   3540 Jun 29 20:23 README.md
drwxr-xr-x  3 david david   4096 Jun 29 20:23 scripts
drwxr-xr-x 35 david david   4096 Jun 29 20:32 vendor
drwxr-xr-x  8 david david   4096 Jun 29 20:32 web

I'm installing it on a folder inside my home folder.

Create an API that would be hard to tell that it's Drupal backed.

Add a checklist of things to do in order to be production ready:

• Set up CORS headers.
• Simplify the consumer to make only simple requests.
• Add trusted hosts.
• Enable all caches.
• Enable syslog, disable dblog
• Ensure to not show PHP errors
• Turn off unnecessary modules
• Review the status reports