drop's picture

Please use this topic to suggest agenda items for our weekly meetings.

This week we will be having an UX/Design meeting followed by a the weekly Dev meeting. 

For more information about our weekly meetings: https://backdropcms.org/news/meetings

Comments

BackdropCMS.org log is full of errors. But it is difficult to debug since many of the errors occur as a result of GitHub webhooks. Forking the borg codebase locally therefore doesnt help since local doesnt receive webhooks. And we cant debug safely on the live site. We need therefore either:

  • a Dev site for BackdropCMS.org that receives the same webhooks as the real site, or
  • duplicate the current webhooks to tunnel service like ngrok. We'd need to figure out how to distribute access.

A note about ngrok and webhooks: 

In the Backdrop Contrib repo settings, there is a section for setting up webhooks (I have no access to this so cant screenshot or describe the setup), so that when events occur on the repo (releases are the main event we're interested in this issue) we've setup the repo to ping a specific URL like https://backdropcms.org/webooks (not the real URL) with data about the release. This triggers things like packaging the zip files etc.

But this webhook only targets that one URL, so even if you fork b.org, releases wont ping your http://testsite.localhost/webhooks. Local dev to debug release events then becomes very difficult.

Ngrok helps: you add an ngrok URL same place where you put https://backdropcms.org/webooks in the GitHub repo webhook settings, so the repo also pings http//on54o6565inoi.ngrok.com (made that up too). Then you have a local ngok client that sets up a tunnel to ngrok and ngrok forwards the webhook to that client, which (locally) pings http://testsite.localhost/webhooks with the same payload. 

IANAE, and there are alternatives, so putting this out here as a starter for discussion.

jenlampton's picture

a Dev site for BackdropCMS.org that receives the same webhooks as the real site, 

This is a great idea. We do have a beta site for backdropcms.org (as of the last week or so). We should set up all the webhooks for it also. I've created https://github.com/backdrop-ops/backdropcms.org/issues/873 as a placeholder but it would help if someone could flush out what would be necessary to get that going! 

indigoxela's picture

Suggestion for the DEV meeting:

Work continues to consolidate the file access functions,  that's issue #5480.

In addition to that (and the questions on the related PR), there's now also a question (#5517) if we can standardize the xxx_access functions, and an alternate suggestions to create new methods.

Background to all this work:

Entity Plus is the most used Backdrop module. Not because it provides fancy new functionality, but because almost all modules ported from D7 that required the Entity module need something that's not currently provided by Backdrop core.

There's nothing wrong with Entity Plus, but the fact that so many modules require it shows clearly, that essential functionality is missing in core. We should fix that (step by step). Generic access checks are only a small part of it.