Ohio, USA
Account created on 16 November 2016, over 7 years ago
  • Senior Front-End Developer at LullabotΒ  …
#

Merge Requests

Recent comments

πŸ‡ΊπŸ‡ΈUnited States andy-blum Ohio, USA

One thing that we may want to consider & will start to get tricky is browser testing on iOS. As of iOS 17.4, iOS will begin to allow browser engines other than webkit. The requirements for this are pretty strict right now, but there's the potential for browser applications availalbe in the EU that aren't available anywhere else.

πŸ‡ΊπŸ‡ΈUnited States andy-blum Ohio, USA

You should definitely be able to run the command inside ddev.

There are a couple ways to accomplish this:

  1. Run ddev ssh. This will allow you to run commands inside the container.
  2. Run ddev exec php [command]. This will pass the command into the container and then running it without changing your entire CLI environment

The tricky part of the second version is you have to know what the current working directory is. By default it's /var/www/html/, and if your drupal installation is inside a "web" directory, you have to add that part to your command.

Try running ddev exec php web/core/scripts/drupal generate-theme mytheme and see if that works.

πŸ‡ΊπŸ‡ΈUnited States andy-blum Ohio, USA

Core/scripts/drupal is an extensionless file, not a folder. It is the 7th item in your screenshot.

πŸ‡ΊπŸ‡ΈUnited States andy-blum Ohio, USA

Adding a comment here just to bump this issue back to the top of my dashboard.

πŸ‡ΊπŸ‡ΈUnited States andy-blum Ohio, USA

inverted-colors is widely unsupported. I'd suggest removing it from your list.

πŸ‡ΊπŸ‡ΈUnited States andy-blum Ohio, USA

Test failures appear to be aligned with current failures against 1.0.x

πŸ‡ΊπŸ‡ΈUnited States andy-blum Ohio, USA

Moved Phil's patch into the MR and fixed PHPCS errors

πŸ‡ΊπŸ‡ΈUnited States andy-blum Ohio, USA

andy-blum β†’ made their first commit to this issue’s fork.

πŸ‡ΊπŸ‡ΈUnited States andy-blum Ohio, USA

The MR changes code only in Claro, so updating this to the Claro issue queue.

πŸ‡ΊπŸ‡ΈUnited States andy-blum Ohio, USA

Typically code changes should be submitted as patches or MRs - that way the testing infrastructure can review the code as well. Your CSS, however, is not a bug fix. Your CSS is a change based on your opinion of a design that was finalized several years ago, and that is in active use in sites. Changing this design in Olivero now would cause regressions in existing sites. As such, I have continually marked this as "works as designed".

Again, if this change is something you feel that strongly about, I recommend using the starterkit patch provided above or some other method for creating your own custom solution.

πŸ‡ΊπŸ‡ΈUnited States andy-blum Ohio, USA

The empty column is there because the website layout has been deliberately limited to a max-width of 98.125rem. Without this limitation, the website would spread across the entire screen hindering readability of the content and causing large swaths of empty space between the content, the logo, and the navigation.

If this is not acceptable to you, you are free to make a new theme using Olivero as a starterkit πŸ“Œ [PP-1] Allow starterkit theme generator tool to clone Olivero Postponed . This design of Olivero has been finalized for quite some time now and it will not be changing. Please stop re-opening this issue.

πŸ‡ΊπŸ‡ΈUnited States andy-blum Ohio, USA

Page content is limited in width for readability.
https://css-tricks.com/six-tips-for-better-web-typography/

Page layout is limited in width to keep the rest of the page elements in the same general area with the page content.

If you think this layout would look better center aligned, I'd direct you to a different issue, πŸ“Œ Olivero: Center align content (instead of left align) Needs work .

πŸ‡ΊπŸ‡ΈUnited States andy-blum Ohio, USA

we still want to convert values to custom properties

Is this necessary since the classes aren't obfuscated, the styles are BEMified, and everything is brought in via the Library API? I think once the plan outlined in #3394904 is done and the styles in PB are reduced to just basic layout styles (similar to the views module when viewed in Stark), admin themes will be responsible for theming the PB UI.

allow prefix/suffix inserting with Drupal.theme()

This probably needs someone investigating if this can be done safely. I imagine Drupal.theme() will break a lot of the svelte event bindings.

πŸ‡ΊπŸ‡ΈUnited States andy-blum Ohio, USA

Marked as ready to kick off an initial round of tests to make sure I'm on the right track.

πŸ‡ΊπŸ‡ΈUnited States andy-blum Ohio, USA

andy-blum β†’ made their first commit to this issue’s fork.

πŸ‡ΊπŸ‡ΈUnited States andy-blum Ohio, USA

This issue feels nullified by the resolution outlined in the issue description on πŸ“Œ Move styles out of svelte bundle to traditional Drupal library Fixed

πŸ‡ΊπŸ‡ΈUnited States andy-blum Ohio, USA

Is this issue still relevant after πŸ“Œ Move styles out of svelte bundle to traditional Drupal library Fixed

πŸ‡ΊπŸ‡ΈUnited States andy-blum Ohio, USA

The changes to <MediaQuery> can be seen in isolation here

The goal here is to avoid needing to add in duplicate MediaQuery components to get effects at the same breakpoint. The MQ component now adds that value into a Map where the key is the exact media query string and the value is a boolean.

With this logic, we can now update nested components to simply reference and respond to the values in the store like in this commit

The exact reason this was needed in the first place is that the project grid/list toggles back and forth between the two for both user intiated reasons, as well as automatically when the browser is resized. Prior to this change the following could happen:

  • User loads page on desktop
  • User toggles to list view
  • User resizes browser down to "mobile" breakpoint
  • User resizes browser up to "desktop" breakpoint and the layout is automatically switched back to grid

Now, the value of toggleView is always directly linked to the user's specified preference and we're able to override that when the viewport width necessitates it.

In a highly-simplified version of the code:

ProjectBrowser.svelte handles the media query as well as the user preferences from the list/grid buttons.

<MediaQuery query="(min-width: 1200px)" let:matches>
  <ProjectGrid {toggleView} {loading} {rows} {pageIndex} {$pageSize} let:rows>
    <button on:click={}>List</button>
    <button on:click={}>Grid</button>

    {#each rows as row, index (row)}
      <Project {toggleView} project={row} />
    {/each}
    
  </ProjectGrid>
</MediaQuery>

ProjectGrid.svelte adds the preferred class on desktop breakpoints and the list class on smaller widths

<ul class="projects-{isDesktop ? toggleView.toLowerCase() : 'list'}">
  <slot rows={visibleRows} />
</ul>

Project.svelte does the same thing as ProjectGrid.svelte

<li class="project project--{isDesktop ? toggleView.toLowerCase() : 'list'}">
  
</li>
πŸ‡ΊπŸ‡ΈUnited States andy-blum Ohio, USA

Closing this as duplicate because we're adding this as part of πŸ“Œ Making a theme compatible with core's theme generator is too difficult Needs work

πŸ‡ΊπŸ‡ΈUnited States andy-blum Ohio, USA

Closing this as duplicate because we're adding this as part of πŸ“Œ Making a theme compatible with core's theme generator is too difficult Needs work

πŸ‡ΊπŸ‡ΈUnited States andy-blum Ohio, USA

Test failures are now related to the generate theme command. Abridged failures below:

---- Drupal\Tests\Core\Command\GenerateThemeTest ----
    
Testing Drupal\Tests\Core\Command\GenerateThemeTest
FFFFFFF..                                                           9 / 9
(100%)

Time: 00:56.152, Memory: 12.00 MB

There were 7 failures:

1) Drupal\Tests\Core\Command\GenerateThemeTest::test
Failed asserting that two strings are equal.
--- Expected
+++ Actual
@@ @@
-'starterkit_theme:9.4.0'
+'test_custom_theme:1.0.0'


2)
Drupal\Tests\Core\Command\GenerateThemeTest::testGeneratingFromAnotherTheme
In InfoParserDynamic.php line 67:

  The 'core_version_requirement' key must be present in themes/test_custom_theme/test_custom_theme.info.yml


generate-theme [--name [NAME]] [--description [DESCRIPTION]] [--path
[PATH]] [--starterkit [STARTERKIT]] [--] 


Failed asserting that two strings are identical.
--- Expected
+++ Actual
@@ @@
-'Theme generated successfully to themes/generated_from_another_theme'
+''


3) Drupal\Tests\Core\Command\GenerateThemeTest::testDevSnapshot
Failed asserting that 'test_custom_theme:1.0.0' matches PCRE pattern
"/^starterkit_theme\:9.4.0-dev#[0-9a-f]+$/".


4) Drupal\Tests\Core\Command\GenerateThemeTest::testContribStarterkit
Failed asserting that two strings are equal.
--- Expected
+++ Actual
@@ @@
-'starterkit_theme:1.20'
+'test_custom_theme:1.0.0'


5) Drupal\Tests\Core\Command\GenerateThemeTest::testContribStarterkitDevSnapshot
Failed asserting that two strings are equal.
--- Expected
+++ Actual
@@ @@
-'The source theme starterkit_theme has a development version number
(7.x-dev). Because it is not a git checkout, a specific commit could not be
identified. This makes tracking changes in the source theme difficult. Are
you sure you want to continue? (yes/no) [yes]:\n
- > Theme generated successfully to themes/test_custom_theme'
+'Theme generated successfully to themes/test_custom_theme'

6) Drupal\Tests\Core\Command\GenerateThemeTest::testContribStarterkitDevSnapshotWithGitNotInstalled
Failed asserting that two strings are equal.
--- Expected
+++ Actual
@@ @@
-'[ERROR] The source theme starterkit_theme has a development version
number     \n
-         (7.x-dev). Determining a specific commit is not possible because
git is\n
-         not installed. Either install git or use a tagged release to
generate a\n
-         theme.'
+'Theme generated successfully to themes/test_custom_theme'

7) Drupal\Tests\Core\Command\GenerateThemeTest::testCustomStarterkit
Failed asserting that two strings are equal.
--- Expected
+++ Actual
@@ @@
-'The source theme starterkit_theme does not have a version specified. This
makes tracking changes in the source theme difficult. Are you sure you want
to continue? (yes/no) [yes]:\n
- > Theme generated successfully to themes/test_custom_theme'
+'Theme generated successfully to themes/test_custom_theme'

FAILURES!
Tests: 9, Assertions: 32, Failures: 7.
πŸ‡ΊπŸ‡ΈUnited States andy-blum Ohio, USA

Symfony's finder & filesystem components are now full runtime dependencies [ CR β†’ ]

πŸ‡ΊπŸ‡ΈUnited States andy-blum Ohio, USA

Symfony's finder & filesystem components are now full runtime dependencies [ CR β†’ ]

πŸ‡ΊπŸ‡ΈUnited States andy-blum Ohio, USA

I ran these tests locally and was unable to replicate the errors associated with #5e6988c5. I wanted to re-run the tests, but I don't see that as an option anymore on the d.o test results page.

I've updated a CSS selector for the sake of making a new push instead.

πŸ‡ΊπŸ‡ΈUnited States andy-blum Ohio, USA

I think your option 4 is the same as my option 2, though?

πŸ‡ΊπŸ‡ΈUnited States andy-blum Ohio, USA

I love this idea, and think an addition to the libraries.yml would be the perfect place to declare es module usage. For example from the react module's current usage of the importmaps module:

react.libraries.yml

react:
  js:
    'js/dist/react.js': { minified: true }

react-dom:
  js:
    'js/dist/react-dom.js': { minified: true }
  dependencies:
    - react/react

react.importmaps.yml

react:
  path: js/dist/react.js
react-dom:
  path: js/dist/react-dom.js
react/jsx-runtime:
  path: js/dist/react-jsx-runtime.js

To kick off some discussion here, re-imagining this as a single .libraries.yml file could become one of several options, each with their own benefits/drawbacks.

Option 1: Adding importpath info to a JS asset

react:
  js:
    'js/dist/react.js': { minified: true, esmodule: 'react' }

react-dom:
  js:
    'js/dist/react-dom.js': { minified: true, esmodule: 'react-dom' }
  dependencies:
    - react/react

Pros:

  • Minimal addition to the yaml structure
  • Tight coupling to current libraries

Cons:

  • JS files don't necessarily need to be loaded on a page for the import map to work, but this approach would add them into the DOM 100% of the time

Option 2: Adding importpath info to an individual library

react:
  js:
    'js/dist/react.js': { minified: true }
  imports:
    'react': 'js/dist/react.js' 

react-dom:
  js:
    'js/dist/react-dom.js': { minified: true }
  imports:
    'react-dom': 'js/dist/react-dom.js'
  dependencies:
    - react/react

Pros:

  • Moderate coupling to current libraries
  • Files that exist only as "sources" of modules won't get unnecessarily loaded to the page

Cons:

  • Files that both need to both run *and* operate at a module's source have to be duplicated

Option 3: Adding importpath info as a separate non-library top level item

react:
  js:
    'js/dist/react.js': { minified: true }

react-dom:
  js:
    'js/dist/react-dom.js': { minified: true }
  dependencies:
    - react/react

IMPORT_PATH:
  'react': 'js/dist/react.js'
  'react-dom': 'js/dist/react-dom.js'

Pros:

  • Offers the greatest flexibility

Cons:

  • Loosest coupling to libraries
  • Requires a "magic" library name
πŸ‡ΊπŸ‡ΈUnited States andy-blum Ohio, USA

We are moving in the wrong direction.

πŸ‡ΊπŸ‡ΈUnited States andy-blum Ohio, USA

@deborahblessy

As Eli said, thank you for contributing!

I took a quick look at your patch and wanted point out that while {3,6} does match the 3-character syntax for hex codes, the regex as you've written it will also match to invalid 4- and 5-character strings. Additionally, the HTMLColorInput that we create in color-picker.js will only accept a full 6-character string, so we have to also flesh out any 3-character strings before we try to set that element's value.

Since your patch passes the tests but would cause problems in real situations, we probably have a need for some additional tests. I'll open a followup issue for those.

πŸ‡ΊπŸ‡ΈUnited States andy-blum Ohio, USA

andy-blum β†’ made their first commit to this issue’s fork.

πŸ‡ΊπŸ‡ΈUnited States andy-blum Ohio, USA

The change to the JS shouldn't have any side-effects. I agree with @GoZ's assessment that running the JS in strict mode is likely the cause of the issue. At Lullabot, we've made the decision to write all JS using strict mode, but likely haven't encountered this exact error since I don't believe we're using advagg.

in attempting to follow @GoZ's instructions, I couldn't reproduce the issue. That being said, using `this` outside of object-oriented code raises red flags and I think this change to a more explicit `window` is a good decision. I've attached some screenshots to hopefully demonstrate that the changes of `this` to `window` in the scope of an IIFE do not impact



πŸ‡ΊπŸ‡ΈUnited States andy-blum Ohio, USA

Is this issue still relevant? Should it be replaced by πŸ“Œ Refactor Claro's dropbutton stylesheet Needs review ?

πŸ‡ΊπŸ‡ΈUnited States andy-blum Ohio, USA

Opened ✨ Add Symfony's Filesystem and Finder components to core Active for the work following this dependency evaluation.

πŸ‡ΊπŸ‡ΈUnited States andy-blum Ohio, USA

Opened ✨ Add Symfony's Filesystem and Finder components to core Active for the work following this dependency evaluation.

πŸ‡ΊπŸ‡ΈUnited States andy-blum Ohio, USA

andy-blum β†’ made their first commit to this issue’s fork.

πŸ‡ΊπŸ‡ΈUnited States andy-blum Ohio, USA

There are two primary arguments I have against requiring core-dev as a solution to this issue:

  1. core-dev is not bundled into the tarballs which can be downloaded from Drupal core's project page - in fact there's no messaging on that page at all advocating for composer installation as a preferred method.
  2. The starterkit tool is grouped with recipes and distributions as a tool to reduce the barrier of entry for newer and less experienced developers. I don't believe requiring core-dev is in line with serving that audience, even if it's a relatively easy task to add/remove.
πŸ‡ΊπŸ‡ΈUnited States andy-blum Ohio, USA

Assigning this to myself to work on at DrupalCon Lille.

πŸ‡ΊπŸ‡ΈUnited States andy-blum Ohio, USA

While the example provided here isn't valid, it does highlight a problem that could be experienced with very long words on the mobile layout. For example, if we add a very long german word, we can experience the overflow issue identified here.

By adding the hyphens: auto; CSS rule, we can get that word to break in a language specific way.

Language support depends on browser implementation, which is poor according to MDN, but that information appears to be out-of-date

πŸ‡ΊπŸ‡ΈUnited States andy-blum Ohio, USA

Per the designs, as the screen size shrinks, the sidebar is moved below the main content and is allowed to take up more space on the grid container. If you have design suggestions, please share them, but as-is, I don't believe this is an issue.


πŸ‡ΊπŸ‡ΈUnited States andy-blum Ohio, USA

would it be possible to alphabetize the components as well?

πŸ‡ΊπŸ‡ΈUnited States andy-blum Ohio, USA

andy-blum β†’ made their first commit to this issue’s fork.

πŸ‡ΊπŸ‡ΈUnited States andy-blum Ohio, USA

There is currently an option for "custom location" that does nothing right now. It's effectively identical to the "bundled version" option.

I'm envisioning something similar to the favicon & logo settings where admins can set their own paths.

πŸ‡ΊπŸ‡ΈUnited States andy-blum Ohio, USA

Removed outdated info from "about" section.

Added settings to use bundled assets or CDN assets on any version.

πŸ‡ΊπŸ‡ΈUnited States andy-blum Ohio, USA

andy-blum β†’ created an issue.

πŸ‡ΊπŸ‡ΈUnited States andy-blum Ohio, USA

I am qualified to review the CSS 😁

Everything here looks fine. The nits below are completely optional.

.banner-block__image img {
    position: absolute;
    top: 0;
    left: 0;
    width: 100%;
    height: 100%;
    object-fit: cover;
}

"top" and "left" could be replaced with a single "inset:0;". This reduces the CSS by a negligible amount and adheres to the best practices of logical properties

.banner-block__content {
    position: relative; /* Establish stacking context to appear above absolutely positioned background image. */
    max-width: 50%;
    margin: 0;
    padding: 1.777em;
    color: #fff;
    border: 1px solid #464646;
    background: rgba(0, 0, 0, 0.42);
}

This is a super pedantic nit, but these rules don't actually create a new stacking context, they just position the content properly (additional info)

πŸ‡ΊπŸ‡ΈUnited States andy-blum Ohio, USA

Is there a reason (either way) to introduce/not introduce them?

The reason for trying to avoid the new dependencies was to speed this along.

If the code is really complicated, does this help make the case for including the dependencies?

I would argue yes.

πŸ‡ΊπŸ‡ΈUnited States andy-blum Ohio, USA

Ready for review.

πŸ‡ΊπŸ‡ΈUnited States andy-blum Ohio, USA
πŸ‡ΊπŸ‡ΈUnited States andy-blum Ohio, USA

I don't believe this is actually an issue, is it? uikit/global-style depends on uikit/uikit, which already declares core/jquery and core/drual as dependencies. Similarly, uikit/active-link depends on uikit/uikit, which depends on core/drupal, which depends on core/drupalSettings

πŸ‡ΊπŸ‡ΈUnited States andy-blum Ohio, USA
πŸ‡ΊπŸ‡ΈUnited States andy-blum Ohio, USA

Jquery is needed, but jquery_ui/_dialog are not. Removing these as part of πŸ› Drupal 10 support currently broken Fixed .

πŸ‡ΊπŸ‡ΈUnited States andy-blum Ohio, USA

Closing in favor of πŸ› Drupal 10 support currently broken Fixed

πŸ‡ΊπŸ‡ΈUnited States andy-blum Ohio, USA

The page content is in a wrapper with a set max width. The β€œdrops” pattern is the background that takes up the remainder of the page instead of blank white.

πŸ‡ΊπŸ‡ΈUnited States andy-blum Ohio, USA

Closing this in favor of the effort to enable Olivero's starterkit compatibility.

πŸ‡ΊπŸ‡ΈUnited States andy-blum Ohio, USA

Closing this as won't fix, as this feature would need to go to the contrib space.

πŸ‡ΊπŸ‡ΈUnited States andy-blum Ohio, USA

What's probably happening here is the CKEditor-default styles are occurring in a stylesheet that's applied after your styles. Because they are in the same context and have the same specificity, the last-defined value wins. You have a few options:

1. Change your selector. If you select an element further down the DOM like .ck-editor__main, you should be able to override the value of the css-variable, even without changing your specificity or context.

2. Alter the ck-editor library. You can use libraries-override β†’ to change the ck-editor library that gets attached for your theme.

3. Move your styles down in the cascade. Your styles are higher in the cascade, and are losing to styles lower in the cascade. You could add a weight to your stylesheet β†’ where those styles are defined between -50 and +50. Higher weights "sink" to the bottom, and lighter weights "float" to the top.

Closing this support request now, but feel free to re-open the ticket if needed.

πŸ‡ΊπŸ‡ΈUnited States andy-blum Ohio, USA

As mentioned above this is an issue outside of olivero. Closing this issue as won't fix.

πŸ‡ΊπŸ‡ΈUnited States andy-blum Ohio, USA

The olivero design keeps content left-aligned in LTR languages, and right-aligned in RTL languages. Attaching the issue working on centering the layout.

πŸ‡ΊπŸ‡ΈUnited States andy-blum Ohio, USA

This is still an issue - planet drupal is currently just pages of undpaul posts.

πŸ‡ΊπŸ‡ΈUnited States andy-blum Ohio, USA

Adding link to relevant webkit bug, postponing issue.

πŸ‡ΊπŸ‡ΈUnited States andy-blum Ohio, USA
To fix, run:

    COMPOSER_ROOT_VERSION=11.x-dev composer update --lock

Ran this as recommended by the test results, but it failed with this:

Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - Root composer.json requires drupal/core == 10.1.9999999.9999999-dev, it is satisfiable by drupal/core[10.1.x-dev] from composer repo (https://repo.packagist.org) but drupal/core[dev-3364885-making-a-theme, 11.x-dev] from path repo (repos/drupal/core) has higher repository priority. The packages from the higher priority repository do not match your constraint and are therefore not installable. That repository is canonical so the lower priority repo's packages are not installable. See https://getcomposer.org/repoprio for details and assistance.
  Problem 2
    - Root composer.json requires drupal/core-dev == 10.1.9999999.9999999-dev, it is satisfiable by drupal/core-dev[10.1.x-dev] from composer repo (https://repo.packagist.org) but drupal/core-dev[dev-3364885-making-a-theme, 11.x-dev] from path repo (repos/drupal/composer/Metapackage/DevDependencies) has higher repository priority. The packages from the higher priority repository do not match your constraint and are therefore not installable. That repository is canonical so the lower priority repo's packages are not installable. See https://getcomposer.org/repoprio for details and assistance.
  Problem 3
    - Root composer.json requires drupal/core-project-message == 10.1.9999999.9999999-dev, it is satisfiable by drupal/core-project-message[10.1.x-dev] from composer repo (https://repo.packagist.org) but drupal/core-project-message[dev-3364885-making-a-theme, 11.x-dev] from path repo (repos/drupal/composer/Plugin/ProjectMessage) has higher repository priority. The packages from the higher priority repository do not match your constraint and are therefore not installable. That repository is canonical so the lower priority repo's packages are not installable. See https://getcomposer.org/repoprio for details and assistance.
  Problem 4
    - Root composer.json requires drupal/core-recommended == 10.1.9999999.9999999-dev, it is satisfiable by drupal/core-recommended[10.1.x-dev] from composer repo (https://repo.packagist.org) but drupal/core-recommended[dev-3364885-making-a-theme, 11.x-dev] from path repo (repos/drupal/composer/Metapackage/CoreRecommended) has higher repository priority. The packages from the higher priority repository do not match your constraint and are therefore not installable. That repository is canonical so the lower priority repo's packages are not installable. See https://getcomposer.org/repoprio for details and assistance.
  Problem 5
    - Root composer.json requires drupal/core-vendor-hardening == 10.1.9999999.9999999-dev, it is satisfiable by drupal/core-vendor-hardening[10.1.x-dev] from composer repo (https://repo.packagist.org) but drupal/core-vendor-hardening[dev-3364885-making-a-theme, 11.x-dev] from path repo (repos/drupal/composer/Plugin/VendorHardening) has higher repository priority. The packages from the higher priority repository do not match your constraint and are therefore not installable. That repository is canonical so the lower priority repo's packages are not installable. See https://getcomposer.org/repoprio for details and assistance.
  Problem 6
    - Root composer.json requires drupal/drupal == 10.1.9999999.9999999-dev, found drupal/drupal[dev-3364885-making-a-theme, 11.x-dev] but these do not match your constraint and are therefore not installable. Make sure you fix the constraint as packages installed from symlinked path repos are updated even in partial updates and the one from the lock file can thus not be used.
  Problem 7
    - Root composer.json requires drupal/devel == 5.1.1.0 -> satisfiable by drupal/devel[5.1.1].
    - drupal/devel 5.1.1 requires drupal/core ^9 || ^10 -> satisfiable by drupal/core[9.0.0-alpha1, ..., 9.5.x-dev, 10.0.0-alpha1, ..., 10.1.x-dev] from composer repo (https://repo.packagist.org) but drupal/core[dev-3364885-making-a-theme, 11.x-dev] from path repo (repos/drupal/core) has higher repository priority. The packages from the higher priority repository do not match your constraint and are therefore not installable. That repository is canonical so the lower priority repo's packages are not installable. See https://getcomposer.org/repoprio for details and assistance.
πŸ‡ΊπŸ‡ΈUnited States andy-blum Ohio, USA

Updated issue summary

πŸ‡ΊπŸ‡ΈUnited States andy-blum Ohio, USA

@ressa I actually don't use images on my site at all!

πŸ‡ΊπŸ‡ΈUnited States andy-blum Ohio, USA

It means no articles will show up now, but new articles in the future would appear, yes?

I have a couple of articles in progress that I’d like to appear when they are published

Production build https://api.contrib.social 0.61.6-2-g546bc20