larowlan → credited shaal → .
benjifisher → credited shaal → .
benjifisher → credited shaal → .
benjifisher → credited shaal → .
To allow styling specific sections in shadow dom, we can always use ::part() https://developer.mozilla.org/en-US/docs/Web/CSS/::part
I did not understand what was the potential issue with Slots / h2 / accessibility. Can you please try explain it again?
benjifisher → credited shaal → .
benjifisher → credited shaal → .
The core of this issue appears to be related to Drupal users who have not accepted the Drupal Terms of Service (TOS).
I've found a way to replicate the problem that new users might encounter:
- Visit https://gitpod.io/user/integrations
- Locate the line that says "GitLab (git.drupalcode.org)"
- Click on the three vertical dots to its right and select "Disconnect"
- Go to https://git.drupalcode.org and ensure you are signed in
- Navigate to https://git.drupalcode.org/-/users/terms
- Click on "Decline and sign out"
- Attempt to open any Drupal project with Gitpod (e.g., https://gitpod.io/#https://git.drupalcode.org/project/drupalpod)
For users who want to quickly resolve this issue, follow these steps:
- Visit https://git.drupalcode.org and ensure you are signed in
- Navigate to https://git.drupalcode.org/-/users/terms
- Click on "Accept Terms"
benjifisher → credited shaal → .
benjifisher → credited shaal → .
benjifisher → credited shaal → .
benjifisher → credited shaal → .
benjifisher → credited shaal → .
benjifisher → credited shaal → .
This was fixed long time ago, but I forgot to update the issue.
Gitpod determines the URL that will be used for the workspace and we have no control over it.
The only thing users can do - is manually update the description of that workspace (under https://gitpod.io/workspaces)
@mradcliffe do you know if this problem exist also in https://github.com/joachim-n/drupal-core-development-project ?
I am planning to integrate Cally in our projects.
It's a web component, which makes it very easy to integrate.
benjifisher → credited shaal → .
benjifisher → credited shaal → .
benjifisher → credited shaal → .
benjifisher → credited shaal → .
In the SVGs from latest brand page I shared above each SVG has both the logo and the word "Drupal" together.
I used Figma to separate the drop SVG, and optimized that SVG through https://jakearchibald.github.io/svgomg optimization.
I then replaced it with existing 2 Drupal Logos I found in the code and updated its fill color with the colors that were already in code, as well as replaced the logo in Claro CSS.
Files updated:
/core/themes/claro/images/core/ffffff/drupal-logo.svg/core/misc/logo/drupal-logo.svg/core/themes/claro/css/components/system-status-report-general-info.css
Was that the change expected in this issue? anything else?
I found all new SVGs through http://drupal.widencollective.com/portals/gfvztttq/BrandPortal (from: https://www.drupal.org/community/promote-drupal → )
benjifisher → credited shaal → .
ChrisDarke → credited shaal → .
What if after initial setup we delete `/workspace/drupalpod/.git` directory? Would that make it simpler for people?
We can also open VSCode welcome screen with clear instructions on project structure, and how to find where is the git they should push code to.
I'm open for ideas as I would like to make it simpler and easier for everyone.
benjifisher → credited shaal → .
Thank you! Yes, there was a recent update in DrupalPod, where it is now hosted in d.o instead of Github, which means users do NOT need to follow the old SSH process, and now the transition is much simpler.
Follow up steps I would recommend:
* Test the experience of a NEW drupal.org user (I am not sure if they still need to do something with their account to get access to push code)
* Update DrupalPod repo with new instructions
* Update DrupalPod VSCode extension with new instructions.
Thank you, @rfay.
The original idea (and perhaps it was confusing, but I was trying to add context) was that most developers are probably familiar with a "normal" modern Drupal setup, where Drupal is installed under `/web` or `/docroot`, and dependencies are managed by Composer.
Currently, it's not possible to manage Drupal core with Composer; only a "drupal/recommended-project" can be managed.
Because of that, the "website" being set up by DrupalPod is under `/workspace/DrupalPod`.
Under that directory, users should expect a "normal" modern installation, where contributed modules are under `/web/modules/contrib`, and the core is under `/web/core`.
When users choose to work on Drupal core issues, the git repository of Drupal core itself is directly available in `/web/core`. When working on a contributed module, the git repository of that module is directly available at `/web/modules/contrib/my_module`.
This allows the Drupal installation to use the updates the user is making in the current installation.
The git repositories are symlinked from `/repos/drupal` or `/repos/my_module`.
The DrupalPod setup itself is 'hidden' under `.gitpod/`, and the ddev setup is 'hidden' under `.ddev/`.
In summary, the DrupalPod installation is supposed to provide a familiar Drupal website setup, where all directories are well-known.
I'd love to hear your thoughts.
benjifisher → credited shaal → .
benjifisher → credited shaal → .
Thank you @tyler36, I sent this information to Gitpod, and awaiting next steps.
In my experience, when I push code from Gitpod, I am getting a warning in VSCode that some permissions are missing, yet the code itself - does get pushed into Drupal's git (e.g. https://git.drupalcode.org/project/drupalpod/-/commit/f83588def03aaa6118...)
Thank you for submitting this.
I will update the PHP requirements for Drupal 11.
@drumm I've been troubleshooting the issue with Gitpod team.
Their latest request is -
An admin of Drupal's GitLab instance needs to enable the read_repository scope for OAuth application in the GitLab preferences. After that you should be able to update it in https://gitpod.io/user/integrations without any errors.
Would that be possible to do?
benjifisher → credited shaal → .
benjifisher → credited shaal → .
benjifisher → credited shaal → .
benjifisher → credited shaal → .
volkswagenchick → credited shaal → .
volkswagenchick → credited shaal → .
This patch fixes an edge case where file stage proxy + webp, doesn't allow checking the width of a public URI.
And fixing a bug in my own previous patch...
Fixing a couple of bugs found in previous patch
benjifisher → credited shaal → .
benjifisher → credited shaal → .
benjifisher → credited shaal → .
benjifisher → credited shaal → .
Is this issue a duplicate of 🐛 Uncaught TypeError: Cannot read properties of null (reading 'style') (toolbar.js) Needs work ?
@drumm, thank you for your help with this.
Opening any Drupal project hosted on git.drupalcode.org in Gitpod establishes Gitpod authorization for the user.
To test this, I opened the following URL in my browser:
https://gitpod.io/#https://git.drupalcode.org/project/drupalpod
I clicked on the "Authorize" link, which opened a new window where I authorized Gitpod. After authorizing and refreshing the original URL, I was able to open the project in Gitpod.
However, when I tried pushing code back to Drupal, I received an error. Looking at the Gitpod permissions in https://gitpod.io/user/integrations, it seems the missing "write_repository" is likely the cause.
(As the screenshot shows, Gitpod currently only showing "read_user" and "read_org" permissions enabled. It does not seem possible to enable even the "read_repository" permission at this time.)
@drumm, could you please add the write_repository? That is the original intent of this issue.
benjifisher → credited shaal → .
benjifisher → credited shaal → .
+1
@finnsky is doing fantastic work! thank you
When styling anchor elements, it might be better to use the :link pseudo-class instead of styling the a element itself. The :link selector specifically targets anchors containing an href attribute, while avoiding styling anchor elements with just a name.
Using :link improves specificity and avoids inadvertently styling elements that aren't links.
Reference:
https://developer.mozilla.org/en-US/docs/Web/CSS/:link
benjifisher → credited shaal → .
benjifisher → credited shaal → .
There's a really nice technique to animate dropdowns using CSS grid.
volkswagenchick → credited shaal → .
volkswagenchick → credited shaal → .
volkswagenchick → credited shaal → .
benjifisher → credited shaal → .
benjifisher → credited shaal → .
volkswagenchick → credited shaal → .
Update gitpod info and added a link to gitpod CDE page
benjifisher → credited shaal → .
benjifisher → credited shaal → .
I think using the CSS trick described here
https://www.youtube.com/watch?v=B_n4YONte5A
would achieve a smooth transition for any height (since the browser handles it).
For accessibility, the patch should include support for reduced-motion
@media (prefers-reduced-motion: no-preference) {
.claro-details--accordion-item {
transition: max-height 1s ease-in-out;
}
}
benjifisher → credited shaal → .
benjifisher → credited shaal → .
benjifisher → credited shaal → .
I think the right side-panel is a separate issue, out of the scope of the code of same_page_preview itself.
In my opinion, most people would prefer using the real estate of the editing page for the live preview side by side, and deal with metadata somewhere else, probably at the bottom of that page.
Here's an example of how same_page_preview side-by-side to editing form, using flex.
(Which will allow narrow screens to display the preview below the edit form)
I gave a session on APCA and fluid typography
benjifisher → credited shaal → .
benjifisher → credited shaal → .
benjifisher → credited shaal → .
benjifisher → credited shaal → .
Vue is the best. :)
It's easy to learn and it's easy to understand even for people who don't know Vue yet.
I saw this post #3145958: [META] Re-evaluate use of Backbone.js in core → yesterday, and I thought - Vue could probably be a good replacement for whatever backbone was used for!