San Francisco Bay Area
Account created on 16 September 2009, over 15 years ago
#

Recent comments

πŸ‡ΊπŸ‡ΈUnited States cellear San Francisco Bay Area

Added myself (cellear) to the notifications list in the issue summary

πŸ‡ΊπŸ‡ΈUnited States cellear San Francisco Bay Area

I'm benchmarking Joomla

πŸ‡ΊπŸ‡ΈUnited States cellear San Francisco Bay Area

Success, I was able to use the image uploaded to this image in the map.

https://www.drupal.org/community/events/badcamp-2024-2024-10-24 β†’

πŸ‡ΊπŸ‡ΈUnited States cellear San Francisco Bay Area

cellear β†’ created an issue.

πŸ‡ΊπŸ‡ΈUnited States cellear San Francisco Bay Area

Since "Starshot" is an (interim?) working project name, and not a consumer-facing brand name,
and since "Drupal Gardens" is an inspiration, but we don't want to step on their trademarks/namespace or
over-emphasise connections that aren't really there, how about...

Starshot Gardens?

That would let us kick the can down the road, identify the initial influences of Starshot and Drupal Gardens, but still
leave us a little time to figure out branding once the product starts to come into better focus.

πŸ‡ΊπŸ‡ΈUnited States cellear San Francisco Bay Area

I just wanted to jump in here quickly and rebut @cilefen's theory that this issue is the "same" as #3377310. It's definitely not. 3377310 is specifically about caching issues, with thoughts put forth that it might be caused by Varnish, WAFs, and other enterprise-level factors. I can rebut it because I'm getting the same error consistently in a range of environments (both hosted and in Docker/Lando containers) and I definitely don't have any kind of fancy cache installed. It's something else.

For the record, here's what Watchdog says on one of them, in this case Drupal 10.1.8/PHP 8.1.27 under Lando:

Location	https://phase4.lndo.site/sites/default/files/js/jquery-2.1.0.js
Referrer	https://phase4.lndo.site/?_webform_dialog=1&token=6mBRf5hY-hXeiCNGLUokvKRfltOSTE1sTCMdJ2CWu44
Message	Symfony\Component\HttpKernel\Exception\BadRequestHttpException: The theme must be passed as a query argument in Drupal\system\Controller\AssetControllerBase->deliver() (line 132 of /app/web/core/modules/system/src/Controller/AssetControllerBase.php).
Severity	Warning

In my case, I was able to get this warning to go away by giving it a dummy file at sites/default/files/js/jquery-2.1.0.js. (That didn't actually fix my problem, but it made the message go away.)

But if anybody else ends here the same way I did -- by Googling the error message we see in Watchdog -- I wanted them to understand that whatever caused this problem is still out there. This bug has not been resolved.

πŸ‡ΊπŸ‡ΈUnited States cellear San Francisco Bay Area

Staying on old technology doesn't make sense except when there is no replacement for it.

Symfony was first released in 2005.  It's just as old, if not older, than Drupal 7 (depending on how you want to measure it.)

Both Backdrop and "Enterprise" Drupal are about 10 years old at this point.  They've grown up in similar environments with similar goals and requirements.  The biggest difference is their level of independence.  The Drupal project made a deliberate decision to "get off the island" and build on top of other technologies, notably Symfony, Composer, and Twig.  Backdrop simply stayed on the island, where they continued to build on what was there. 

The benefits of Drupal's new approach are mostly realized in large systems maintained by dedicated teams, at the cost of considerable complexity.  For example, Drupal users are forced to upgrade very frequently, whenever one of its dependencies (notably Symfony) updates, while Backdrop can (and does) maintain much greater compatibility. While both Drupal 10 and Backdrop will run just fine on the the latest version of PHP (8.2) Drupal 10 requires at least version 8.1, and won't run on a three-year-old environment. In contrast, Backdrop will run on PHP 5.6, so it will still work on an environment that hasn't been updated since 2014.

Drupal is no longer a viable option for sites that can't afford to hire several full-time people to maintain it; Backdrop (like Wordpress) is.

πŸ‡ΊπŸ‡ΈUnited States cellear San Francisco Bay Area

Most (all?) of the comments so far have addressed words that are used in the Drupal interface, which of course is reasonable and necessary. I would like to add a few words that are commonly used in Drupal culture, and which are so pervasive that I think they really mess us up.

I'll dive right into it.

  • Developer. The rest of the world calls people who are able to start with an uninitialized web hosting account and leave a working production-ready website in its place "Web Developers" -- but for some reason in Drupal we call them (often derisively) "Site Builders."
  • The world "Developer" in Drupal is reserved for PHP coders who are adept at creating modules. While this is an important and useful skill, it shouldn't be the only definition of "developer" we acknowledge. This might sound like minor and persnickety complaint, I actually think this is one of the primary causes of the infamous "Drupal Cliff" -- it explains why projects have so much trouble finding Drupal people for their projects. They're looking for the wrong people! Most project need a master Site Builder full-time, with access to module development skills if needed -- but they advertise for "Drupal Developer" and end up with expensive coding resources who create custom modules for functions that are easily handled in Views.

  • Themer. The rest of the world calls them "Front End Developers" and we should just use that terminology.
  • Site Builder. We need to stop acting as if they're some sort of beginner-level developer. Drupal allows for the creation of very sophisticated and capable information architectures within its interface, this is a real and important skill.

A fully-fleshed out Drupal team typically includes not just module developer and FEDS, but "site builders", Dev-ops/sysadmins, content editors, graphic artists, and important consultants like Accessibility and security experts. Only a small portion of these very capable professional need to have the Drupal API memorized; they rest do different things.

πŸ‡ΊπŸ‡ΈUnited States cellear San Francisco Bay Area
πŸ‡ΊπŸ‡ΈUnited States cellear San Francisco Bay Area

I came here to report this issue, and to suggest a solution. I'm not familiar with the details about how the release numbers are stored to know if my proposed solution is plausible, so I'll just spit it out and let it be judged.

I've been spending time studying the D7 releases on the Usage statistics for Drupal core page β†’ , and I noticed that the first nine single-digit releases are mixed in alphabetically with two-digit releases that start with the same digit:

My proposed solution: add a leading zero to the single-digit releases. That would allow them to sort alphabetically where you would expect to find them.

(Note that I realize this would set us up for a "Drupal 7.100" bug.)

πŸ‡ΊπŸ‡ΈUnited States cellear San Francisco Bay Area

Here's a very concise article about using the common unix utility wget to archive a site as static HTML, written by Stanford Web Services resident guru John Bickar.

https://swsblog.stanford.edu/blog/creating-static-copy-website.html

(Which is itself a static version of a Drupal page)

John posted it during Kristen Pol's talk at Stanford Web Camp today:

A survey of decoupled and static website solutions

(I usually do refer to this page: https://www.linuxjournal.com/content/downloading-entire-web-site-wget)

πŸ‡ΊπŸ‡ΈUnited States cellear San Francisco Bay Area

@ressa Thanks for the resources, those are great! I didn't realize that Migrate Accelerate was open source -- and I used to work for Acquia. (I only knew it as a product...now I'm keen to try it)

πŸ‡ΊπŸ‡ΈUnited States cellear San Francisco Bay Area

Count me in!

I've linked to this issue from the d7-soft-landing Slack Channel for visibility.

πŸ‡ΊπŸ‡ΈUnited States cellear San Francisco Bay Area

I removed this paragraph, because it points to a reference that is not longer at this URL:

For a crash course, but with some real depth, check out Understanding Drupal 8. It provides an overview of many of the key APIs introduced in Drupal 8/9.

The referenced URL - https://cipix.nl/understanding-drupal-8-part-1-general-structure-framework - now redirects to "https://cipix.nl/nl" which is a non-English page.  (Dutch, I imagine?  I didn't try to translate it.)

From the WayBack Machine, we can see that as of Aug 8. 2022 there was a blog post at that URL

https://web.archive.org/web/20220810014651/https://cipix.nl/understandin...

(Though frankly it was already pretty dated by then, which might be why it was taken down.)

The material in the four pieces could probably be updated and hosted, but in its current condition it doesn't make sense to keep this link here.

For stylistic reasons, I added combined the two short paragraphs around this deleted section.

πŸ‡ΊπŸ‡ΈUnited States cellear San Francisco Bay Area

cellear β†’ created an issue.

Production build 0.71.5 2024