🇨🇦Canada @Jaypan

I see that tarball support has been removed from Drupal core as of 10.4.0 → :

• Using Composer is the only way to safely and correctly add new code to a Drupal installation. Therefore, the following pages (which supported installing modules and themes via file uploads) have been removed without replacement:

  • The "Add new module" page at /admin/modules/install
  • The "Add new theme" page at /admin/theme/install
  • The "Add new module or theme" page at /admin/reports/updates/install

  See the Additional information, deprecations, and API changes related to installing an extension through the user interface → .

It sounds like it's best to just use the calculator class to round. Thanks for the explanations!

Thank you :) I wondered if anyone cared, it's nice to know someone found it useful!

Thanks, I didn't know round was the better option. It would be nice to have a Price::round() helper method then. Is there any reason to not add that to Price? I'll put together a PR if there is no reason to not have it.

jaypan → created an issue.

Somehow the base table is missing from the database. Try uninstalling and re-installing the Media module.

Preprocess functions are how you make variables available to templates. First, you need the template base theme (you can figure this out by enabling template debugging in services.php, then examining the HTML comments). If the template you are working with is user.html.twig, you can implement hook_preproces_user(). Eg:

function HOOK_preprocess_user(&$vars) {
  $vars['some_module_setting'] = \Drupal::config('some_module')->get('setting');
}

Every key of $vars becomes a twig variable, so you can now use in in the user.twig.html template:

{{ some_module_setting }}

jaypan → created an issue.

This file is missing: libraries/bootstrap/dist/js/bootstrap.bundle.min.js

I'd guess something happened to your libraries folder.

Either the path to the images is wrong, or the image files don't exist on that path. You'll have to debug to determine which.

jaypan → created an issue.

Nice response, that's a good summary.

if I make a D11 site right now using the legacy template, there should be no problems, right?

You'll have to deal with the troubles that come from trying to change that template to a different one  in the future. Also, any time you choose a less traveled path, you'll find less support when you run into issues you need support for. Few people are using tarballs or the legacy template, so if/when you run into issues with these, there aren't a lot of people who can provide support, particularly as the people who provide support generally stay on the beaten path (the supported Drupal Composer template).

I'm in shared hosting, and a custom location of the document root is not allowed.

If this is what is stopping you from using Composer, you can change the webroot location in composer.json to whatever your actual webroot is.

I've verified it is indeed the "Measurement ID" and not the property ID (an integer). It's a bit of a nightmare to find in the analytics control panel. Start with the gear at the bottom left, and started digging around for this ID.

Reported as spam.

Reported as spam.

Above post is reported as spam.

jaypan → created an issue.

I'd hypothesize that Drupal relies on these at a very deep Symfony level, which is why core won't work when they are disabled. That said, the super globals aren't used in Drupal development for, as the thread you linked to mentions, the Syfmony Request object is used instead, as super global values are stored on that object in ParameterBags, and retrieved from there.

I've reported it as spam.

The best way to determine if it's secure is to hire a penetration tester, point at the code you want tested, and have them test it.

Depending on your budget you can also hire penetration testers to test the code. You can point them at the section of your system you want to test and they will try to hack it for you and give you any feedback.

There are few differences between any of Drupal versions 8 and above, so if you find a tutorial for any of them, it will mostly be relevant to other versions, with maybe minor changes.

You do not need drupal/core in composer.json, drupal/core-recommended has drupal/core as a dependency.

Is your name and location relevant to the problem?

I believe you need to declare the default configuration in an override of defaultConfiguration() in your plugin, declaring the keys.

It's not behind, Drupal 7 is still supported.

Instead of this:

$response->addCommand(
  new ReplaceCommand(
    "#edit-names",
    $renderer->render($form['name_container']['names'])
  )
);

Try just returning the array without rendering it:

$response->addCommand(
  new ReplaceCommand(
    "#edit-names",
    $form['name_container']['names']
  )
);

For a test, I'd jack up the memory and see if it loads. If it still doesn't load, you have a problem in your code, creating some kind of loop or something. If it does load, then you have some code using excessive memory and it will require debugging to determine what process is working hard.

This is the perfect opportunity to use a JavaScript debugger in the JavaScript console. All main browsers have one. You start putting breakpoints in the code, and figure out where it is not working, to narrow down the exact problem.

Watch a video or two on YouTube, it's not hard to learn to use a debugger, then you can give more specific information as toward which line of code is not passing, and why not.

When you say it is not working on what system what are you expecting it to do, and what is it actually doing?

The problem is that your forms  all end up with the same Form ID, as node forms are not set up to use a unique form ID for every instance, but rather only differ by content type, and action. EntityForm::getFormId():

public function getFormId() {
    $form_id = $this->entity
        ->getEntityTypeId();
    if ($this->entity
        ->getEntityType()
        ->hasKey('bundle')) {
        $form_id .= '_' . $this->entity
            ->bundle();
    }
    if ($this->operation != 'default') {
        $form_id = $form_id . '_' . $this->operation;
    }
    return $form_id . '_form';
}

If you want to fix your issue, it will take a bit of work.

1. Extend the NodeForm class, and override getFormId. You'll need to add something to ensure it returns a unique value for every instance - likely appending the Node ID or something.

2. Implement hook_entity_type_alter(), and set the form class for nodes to your class:

use Drupal\example\Form\FormOverrideClass;

function hook_entity_type_alter(array &$entity_types) {
    
    /** @var \Drupal\Core\Entity\EntityTypeInterface[] $entity_types */
    $entity_types['node']->setFormClass(FormOverrideClass::class);
}

As I understand it, companies that block VPNs rely on services that are constantly working to determine what IP addresses the VPNs are using. You would need to sign up for one of those services and integrate with Drupal.

It's probably bots looking for attack vectors. But instead they're getting 'page not found', because those pages don't exist.

The list of 'page not found' errors is so you can figure out if you've got bad links, or deleted content on your site that people are visiting, so that you can decide if you want to create the pages for better SEO or user experience or what not.

it only affects sites that do not have a default site configuration

That's not exactly correct, as that would be pretty much every Drupal site, since the default would be Drupal out of the box. From the page:

Under certain uncommon site configurations

And:

The issue is mitigated by the fact that several non-default site configurations must exist simultaneously for this to occur.

While it didn't go into what these configurations would be, as long as you follow the upgrade instructions, you won't have to worry about it.

You can see the actual code that was changed here: https://git.drupalcode.org/project/drupal/-/commit/4a0028124e76440761a5d...

I experimented with this a bit and I found Cypress is very complicated to set up within DDEV if you want to see the tests actually executing in front of your eyes. It has to be able to talk to an X11 server running on the host machine, which has to be set up in a particular way and...sheesh. And that was just on a Mac. I don't know how onerous it would be on Windows.

I set up Cypress to use 'ddev drush' as the Drush command, and it has worked well.

As a huge proponent of Cypress, I am very happy to see this. I, without any knowledge of this action, put forth a a presentation proposal for Drupalcon 2025 to present Cypress and Drupal, so if my presentation is accepted, this will be excellent information to also relay as part of the presentation.

Try updating it, or disabling it, it's something in that module that is causing your issue.

You may also want to search for other people with that error in the issue queue for the module.

Yes. Although I couldn't provide additional assistance on how to do it as a Drupal guy and not a Hardware guy, but I work with Drupal in containers all the time, and Google is almost definitely not going to be configurable in the way you need it to be, if you have the knowledge on how to do it.

I would use the ECA module to set up a rule that deletes the entity after 10 minutes, and then ensure you have cron running on your site every minute. Finally I'd use the Ultimate Cron module and fine tune the frequency at which the various cron implementations on the system should run, setting ECA to 1 minute, but likely reducing all the others to some less frequent value depending on the process.

This seems well suited as a bug report in the issue queue for the module, where I would think you'd be more likely to find assistance for it.

usage of Drupal\Core\Render\Markup::create. Is it safe?

I don't think it is. From the Markup documentation:

This object should only be constructed with a known safe string. If there is any risk that the string contains user-entered data that has not been filtered first, it must not be used.

I was thinking you could use the code from that module as a starting point.

Unfortunately I don't have experience with this module, so I can't assist there, but I see there is a module someone is working on for your exact situation, with an alpha version: https://www.drupal.org/project/paragraphs_migration →

Maybe you can use that code as a starting base.

1. Create a view listing Downtimes
2. Create a contextual reference on the entity reference field referencing the Character
3. Under the 'What do do when the argument is not present', select 'use node ID from URL' (note - texts probably are not exact, I'm going on memory)

Note that step 3 is based on Character entity being a Node. If it's some other type of entity, you'll need to adjust step 3.

This will filter the Downtimes to show only those with a Character ID of the page the block is dropped on to. This means it will only work on Character pages, since the Character has to be part of the page context.

Is your reference from the Character to the Downtime, or from the Downtime to the Character?

What are the issues you are facing? Can you not do the migration of paragraphs the same as you did with terms? They are essentially the same thing - a content entity reference field on the main entity.

Thank you, that was much clearer. It seems Wombatbuddy has answered your question.

There is no official update to the PHP supported versions → for PHP 8.4, so I suspect it hasn't been tested yet, and I'd guess it probably won't be until 8.4 has been released.

I would start with D10 right now. D12 will be released in 2026, meaning Drupal 10 will have support until then. Hopefully your provider will have upgraded their Maria DB version by then, if not you should have a  backup plan to move to a host that provides an updated version of the DB.

How are you attaching these handlers to the form?

There isn't even an alpha release for Drupal 12 yet, so you're probably worrying yourself a little needlessly at the moment.

You will want to set up config splits with the Config split module, and use the Config API to manage your configuration between environments. Using the official Drupal template includes .gitignore files that are pretty good starting points, so that anything that shows up when running git status, probably needs to be committed.

These two tutorials I wrote in a former life are good starting points, and still 95% relevant even on Drupal 10:

https://www.morpht.com/blog/drupal-8-configuration-part-1-configuration-api

https://www.morpht.com/blog/drupal-and-composer-part-1-understanding-com...

You'll need to clearly explain:

1) What you are trying to do overall  - IE what is the functionality you are building?

2) The steps you  have taken to achieve this goal

3) What you expect to happen

4) What is actually happening

Right now as your post is written, the answers to these questions are not clear, and having these answers will make it easier to provide support.

This isn't a Drupal question at all. You'd probably have more success on a Docker forum.

It's extremely rare in Drupal you ever need to work directly with the session. If you need session-like storage, you can use the tempstore.private service.

In forms however, you can store values in the form state, using $form_state->set(), and retrieve values with $form_state->get().

It's extremely rare in Drupal you ever need to work directly with the session. If you need session-like storage, you can use the tempstore.private service.

In forms however, you can store values in the form state, using $form_state->set(), and retrieve values with $form_state->get().

That would be great!

You can use the Migrate API to create your own migration, but it requires understanding how to code in Drupal.

You only posted the backtrace, not the error.

Until it comes back, this may help you move forward with Composer: https://www.morpht.com/blog/drupal-and-composer-part-1-understanding-com...

Look in the Drupal logs at Admin -> reports -> recent log messages to get the actual error message.

You need to also show us the error.

https://www.morpht.com/blog/drupal-8-configuration-part-1-configuration-api

I took a look at your code. Your problem is in the #ajax callback. Your arguments are incorrect, ajax callbacks receive the $form and $form_state arguments. Next, the callback  must return one of the three types listed here → . Almost always you will return an element of the $form object that is passed to the ajax callback.

Well, you have to uninstall on the uninstall tab. And those modules will also list any modules that depend on them.

Maybe you installed a module that depends on Groups, you'll need to uninstall that first.

This can be determined by going to the Admin -> Extend page, finding the groups module, expanding the collapsed data, and seeing if any dependencies are listed.

.scss files are compiled into .css files. When this compilation happens, an additional file is created with the .css.map extension. This file maps the values in the .css file to the locations in the .scss files, so that when you are using an HTML/CSS inspector, the CSS inspector will show you the path to CSS declaration in the .scss file, rather than the .css file. The .css file is what the browser actually reads however. So, your site will work fine if you do not include the .css.map file, but if you include it, debugging CSS becomes easier.

If the file is missing, you can regenerate it by recompiling your .scss files into .css, which will create the .css.map file.

You can't post screenshots to images that are not hosted on Drupal.org. Only links to screenshots on other sites.

Your screenshot didn't come through. But if you have existing groups, you won't be able to uninstall it, so delete any groups you may have then try again. Or post the error you are seeing.

After four years I don't remember.

Display Suite is pretty much legacy these days. Layout Builder is where you're at.  I believe DXPR has switched to using layout builder, but provides much more than just layout builder, it gives a bunch of a handy tools. I personally use Layout Builder now, used Display Suite in the past, and would use DXPR, although I don't currently.

I'm ignoring your spam Darshan.

Empty the database, and delete sites/default/settings.php, then you should be able to start again.

Is cpd_con a custom module? I'm not seeing it for download on Drupal.org, and that's the module where your error is showing.

Many threads here on the forums get left without any answer, and without the context of understanding the community, it can leave new users confused and feel abandoned. I didn't have a solution to your issue, so I thought I'd give you the lay of the land so you could at least understand why, if no one comes along with an answer to your issue. Hopefully someone will come along and assist with the information you need. When people do have the answer, they are generally generous in providing it.

The Drupal community is on ckeditor, which is well tied into Drupal, and over the years I've seen very few people ever mentioning Gutenberg in the forums, so I would imagine you're on your own for the most part with support for that.

Drupal is much, much more powerful than Wordpress (whereas Wordpress is much, much more user friendly for people managing simple sites). Trying to work WP concepts into Drupal is going to create more problems for you than learning the Drupal way things are done.

And finally, if WordPress is meeting your needs, then there probably isn't really a need to switch to Drupal. As awesome as it is, it introduces a lot of complexity (which is what actually makes it awesome). A site that can be done in WordPress is probably best done in WordPress, as it will be easier to operate and maintain.

Not the answer you are looking for, but the FAQ module → may be an alternative.

Security updates.

Duplicate of https://www.drupal.org/project/message/issues/2916602 📌 Create access control handler and create permision Needs review

I would install drush and run 'drush ws' to get some output.

Drupal uses MySQL, PostreSQL and SQLLite as the database backends, and all of these are relational databases. So Drupal is already using a relational database under the hood, you don't need to do anything.

On top of this, since Drupal 8, it's very, very rare to ever directly touch the database for anything, as Drupal has methods to do everything, and database management happens under the hood without a requirement to touch the database. On the contrary, doing stuff directly with the database is an easy way to screw up your Drupal site, as it bypasses APIs that do important stuff.

I have also reported them in the past and now.

It's spam. I don't respond to his posts for that reason. He's trying to build SEO on his name.

Adding a patch that is very rudimentary that creates gnode permissions for view any, and view own, for both entities and entity relations.
Very limited testing so far, but it seems to work.

Yes.

What steps did you take?

How did you remove it manually?

We would need to see the actual #ajax code and callback to be able to help.

I think it probably is, though that's an educated guess. But I think if you point  multiple domains at the same Drupal root, and configured sites.php to route the domains, you should be able to do it.

It's been a few years since I worked on multisite, or on shared hosting though.

The first place to start is looking in the Drupal logs at Admin -> Reports -> Recent log messsages.

Drupal 8 and 9 are no longer supported, so the unsupported module versions are no shown on the page. They are still available through Composer, or if you need to download it, you can click the 'View all releases' link on the module page.

Drupal has a flow of core -> module -> theme. You are working against the flow, which is why you cannot do this, it has to happen at the theme level.

What do you mean?