darren oh → created an issue.
darren oh → created an issue.
darren oh → created an issue.
damienmckenna → credited darren oh → .
darren oh → created an issue.
This is available now at https://www.drupalforge.org/template/drupal-cms-xb
A note about costs: We use Digital Ocean to host demos. Due to the resources required for acceptable performance, we can only run three XB demos on a single Digital Ocean droplet. Each droplet costs $96 per month. We have reduced our standard demo time from six hours to one hour to control costs. Once a Digital Ocean droplet fills up with running demos, new demos take extra long to spin up because a new droplet has to be provisioned. We are working on ways to optimize the process without adding too much to costs.
You can help cover the cost of running the demos by donating at https://opencollective.com/drupalforge.
darren oh → created an issue.
darren oh → created an issue.
volkswagenchick → credited darren oh → .
darren oh → created an issue.
darren oh → created an issue.
Confirmed the fix works.
mradcliffe → credited darren oh → .
mradcliffe → credited darren oh → .
I haven't seen it recently.
I was just made aware of this discussion today. I expect this issue to come up at a Community Working Group meeting in the near future. Speaking for myself, I think a good case has been made for not relying on X/Twitter and Meta for official communications. I also think it is very likely that if we leave those platforms completely bad actors will open accounts in our name and use them maliciously. For that reason I think the Free Software Foundation is wise to recommend that we maintain our presence on those platforms even after we have replaced them with other communication channels.
darren oh → made their first commit to this issue’s fork.
damienmckenna → credited darren oh → .
We found out the DevPanel developers were giving us under-powered containers. This has been fixed and it spun up in 4 minutes in my last test. I'm planning to build an optimized image to reduce launch time further. I appreciate the suggestions for improvement. I’m thinking to keep review for this issue manageable we should make the fewest possible changes to DrupalPod itself until after this is merged in.
darren oh → created an issue.
Hi Randy, thanks for checking it out. Your feedback is appreciated. The configuration is determined by URL parameters.
darren oh → made their first commit to this issue’s fork.
Thanks for the quick turnaround!
volkswagenchick → credited darren oh → .
volkswagenchick → credited darren oh → .
volkswagenchick → credited darren oh → .
Added testing instructions to the PR.
That's the code that runs on GitPod. It does not include the browser extension.
The pull request is on GitHub because I could not find the extension code here. Please point it out to me if I missed it.
Unless there is a plan to remove the Recipe Installer Kit package after installation I don't know what this has to do with the Recipe Installer Kit. However, I did find that, contrary to what I was told by the Drush maintainers, global PHP variables can be set on the command line using the --include option to include a command file that sets a global variable in its class constructor.
darren oh → created an issue.
darren oh → created an issue.
Please allow someone else to review.
I would have preferred the event subscriber because it works no matter how recipes are applied, but I can make this work.
I'll grant that I did not present the full technical case for this in the description. Core already skips validation during installation. If you look at my code, you will see that the $install_state global is initialized to an empty array only if it does not exist. There is zero chance that this will break anything. As I explained, without this change the global variable will not exist for command line scripts that run while installation is paused.
darren oh → created an issue.
This report was based on errors I saw on the command line that I did not see in the Drupal CMS installer. It turned out to be because the installer disables recipe validation. So this issue is just about removing duplicate batch jobs.
darren oh → created an issue.
The blocker for Docker-in-Docker is that it requires at least 8G of memory and we can only afford cheap hosting. To get around that we would need a version of DDEV that can manage other containers in a cluster. The version of DDEV we have now was originally called DDEV Local and has to run on the machine that hosts the containers. There was a companion product called DDEV Cloud acquired by Platform.sh that might serve our needs if Platform.sh allows us to use it.
This works in my tests.
The previous response illustrates why we need support for patches. Lots of bug fixes are blocked from coming to the attention of project maintainers by reviewers who argue against allowing them to be fixed. I hope the Automatic Updates maintainers agree that this project should not be limited to supporting Drupal CMS.
Pull request is ready for review: https://github.com/shaal/drupalpod-browser-extension/pull/12. Tested on Chrome, Firefox, and Safari.
damienmckenna → credited darren oh → .
We're doing a strict check, so the worst that could happen is a few duplicate batch jobs slip through.
darren oh → created an issue.
volkswagenchick → credited darren oh → .
volkswagenchick → credited darren oh → .
volkswagenchick → credited darren oh → .
volkswagenchick → credited darren oh → .
volkswagenchick → credited darren oh → .
volkswagenchick → credited darren oh → .
volkswagenchick → credited darren oh → .
volkswagenchick → credited darren oh → .
volkswagenchick → credited darren oh → .
volkswagenchick → credited darren oh → .
volkswagenchick → credited darren oh → .
volkswagenchick → credited darren oh → .
volkswagenchick → credited darren oh → .
volkswagenchick → credited darren oh → .
volkswagenchick → credited darren oh → .
volkswagenchick → credited darren oh → .
volkswagenchick → credited darren oh → .
volkswagenchick → credited darren oh → .
volkswagenchick → credited darren oh → .
volkswagenchick → credited darren oh → .
volkswagenchick → credited darren oh → .
I agree that it would be better if no one needed patches, but that is outside the scope of this issue. This issue is not even about Drupal CMS. It is about a bug in how Automatic Updates handles the Composer Patches extension. Trying to use this bug to force people to come up with an alternative to patching will turn more people off of Drupal rather than getting them to improve it.
damienmckenna → credited darren oh → .
darren oh → created an issue.
No, Drupal was relying on the locking mechanism to hide this bug from users. Existing sites that bypass the locking mechanism in custom code will now work properly without needing additional workarounds.
A soft dependency would mean Drupal CMS is not automatically updated if the BEF module changes.
It is configurable through permissions.
Fixed duplicate batch jobs. This doesn't remove all dependency errors, but it reduces them and improves performance.