The two issues are related, but I don't think this is a duplicate: the other issue is about how to present the info, this issue is about giving more info. As with art, I know what UX I like but I can't draw a crooked line so I'm perfectly willing to let others handle that aspect of things. No matter what it ends up looking like, the permissions page is going to need more info if anyone expects regular users to use it. Regular users are going to need much more detailed explanations of what various things do.
And, there needs to be some sort of structure rather than confronting them with dozens of permissions from one module. Field UI has 28 permissions and Node has 42. That's going to overwhelm people and dividing the permissions into sections would make it easier for newer users. One of the node permissions is "Bypass content access control"; regular users aren't going to understand what that means, the side-effects, etc etc without a detailed explanation and examples.
tolstoydotcom → created an issue.
I've written code to parse the yml format I gave above and I'll release it as a contrib module within a week or so.
This does not necessarily require changes to core because the parser class I'm replacing (PermissionHandler) is a service (user.permissions) and, unless something's doing something it shouldn't, I should be able to override that. I'll duplicate the code to show the permissions page and replace that path.
Hopefully the core team will see the utility of a much less cryptic permissions page.
My suspicion is this is about annotations not being parsed correctly. If this issue happens to anyone else, please test out the suggestion at the end of #39.
An additional idea is to add sections. For instance, the 'Access any webform configuration' permission could go in an 'admin' section while 'Edit own submission' could go in a 'user' section. Sections would have weights and extended_help. Permissions would also have weights that would control their position within its section. 'section_callbacks' would be similar to 'permission_callbacks'; if both 'section_callbacks' and 'sections' are provided, then sections from the callback(s) are appended to 'sections'.
All of these changes would be optional so current *.permissions.yml files would continue to work, they'd just have one section and no extended_help.
If enough are interested I can make a patch for PermissionHandler::buildPermissionsYaml() to add these optional items to the return from PermissionHandler::getPermissions(). I'd probably use a helper object in buildPermissionsYaml() but the return value of getPermissions() would stay the same. Then, these changes could be worked into the UI.
main:
extended_help: These permissions deal with the webform module. You can probably use the default settings, however, if you want to do [ABC], you might want to [XYZ]. Another possible use case is [ABC2]. In that case you'd [XYZ2].
section_callbacks:
- Drupal\xyz\ABC::xyz
- Drupal\xyz2\ABC::xyz2
sections:
- name: admin
weight: 1
extended_help: something, something, and something
- name: users
weight: 2
extended_help: another thing, another thing, another thing
'access webform overview':
title: 'Access the webform overview page'
section: 'admin'
weight: 1
description: 'Get an overview of all webforms.'
extended_help: Users with this permission can view the page [ABC]. They'll be able to see [XYZ], [ABC2], and [XYZ2]. So, you should only give this permission to users who need to see [ABC].tolstoydotcom → created an issue.
One possibility is to augment *.permissions.yml files so they have "extended_help" sections. For instance, webform.permissions.yml would have:
main:
extended_help: These permissions deal with the webform module. You can probably use the default settings, however, if you want to do [ABC], you might want to [XYZ]. Another possible use case is [ABC2]. In that case you'd [XYZ2].
'access webform overview':
title: 'Access the webform overview page'
description: 'Get an overview of all webforms.'
extended_help: Users with this permission can view the page [ABC]. They'll be able to see [XYZ], [ABC2], and [XYZ2]. So, you should only give this permission to users who need to see [ABC].
There would be the standard question mark in a circle image that users could mouse over to see the extended_help in a popup.
Look in the browser console, the image URLs are probably bad.
I made some minor changes to what's in git and the pages load. I don't know if it will work or not but you can find out:
mkdir temp
cd temp
[put the patch file in temp]
git clone git@git.drupal.org:project/paypal_roles.git
cd paypal_roles
git checkout remotes/origin/8.x-2.x
patch -p1 < ../paypal_roles-2633302-10.patch
Look on admin/reports/dblog. There will also be logs under /var/log/apache2 or similar, but you might need to ask your host to see those.
Those replies raise several questions. Where has it been discussed? Is the discussion open?
"The details will be posted when we have them." Who will supply those details?
I'm not suggesting focusing on cPanel to the exclusion of others. I don't use such control panels and I'm not familiar with their competitors, so read "cPanel" as "cPanel, Plesk, or whatever". But, will such control panels be urged to provide what I described?
Will those "hosted solutions" just be Acquia, Pantheon, and perhaps some other insiders, or could major hosting companies like 1&1, Blue Host, GoDaddy, etc make it part of their offerings? The idea of just reserving this for "Drupal hosts" is self-marginalizing.
tolstoydotcom → created an issue.
Can you search all of the Drupal files for 'logduty'? Maybe it's a contrib module.
If you don't find it, and you don't let visitors register accounts, maybe you got hacked. Does the user have elevated permissions?
It'd be a good idea to replace this, but now there's an SSH class that has things like ssh2_exec($this->connection, 'rm -Rf ' . escapeshellarg($directory)). There's no check if $directory is '/', '/bin', 'bin', '/home/*', etc. That code is in the removeDirectoryJailed method so presumably it's only allowed to operate within a specific directory.
Also, the vendor directory for D11 dev is chock full of calls to exec() and shell_exec(). Symfony even includes an .exe file.
I tried this on a version of D11 dev with 2.0.8 of ECA (I enabled its Content/Core/UI/Views submodules) and I don't see the same issue. In one of the other posts you said it was due to Taxonomy Manager, is that still the case?
Can you start from a blank slate and give a text description of the steps to reproduce this?
Have you tried with other browsers and disabling any extensions in those browsers?
tolstoydotcom → created an issue.
If you do that as it is, someone could hijack your site and your visitors' computers: CSS can load URLs. If you really want to allow this, I'd suggest either a) having an admin with deep CSS knowledge review each submission before allowing it to be published (and make sure the admin doesn't load the CSS in the page, only in a textarea), or b) running it through a CSS parser and having a whitelist of what's allowed.
I assume the new hosting uses a MySQL version that D7 doesn't support. IIRC, every D7 query goes through one function in mysql.inc or similar so you should be able to do a search and replace there.
D9 is no longer supported. What's keeping them from moving to D10? It shouldn't be that difficult.
hongpong → credited tolstoydotcom → .
Please file a bug report in the advagg issue queue.
I based this on the latest dev version. I injected services in the last two places I listed in #23. I didn't deal with the drush code. It'd be great if we could freeze changes to dev for a while, test the patch on D9/D10/D11 (I only tested in on D11), and then deal with drush etc.
To use:
git clone git@git.drupal.org:project/wordpress_migrate.git
cd wordpress_migrate
patch -p1 < ../d11update-3435726-26.patch
I have the dev version of D11 installed and the Drush version is 13.2.0.0. So, that might indicate an issue.
The other thing that I wonder about is #3. It'd probably be better to change the web server config to serve out of the 'web' directory. If you can't do that, move the installation so index.php etc are in 'public_html' and 'vendor' is above it. You'll probably need to change 'web' to 'public_html' in composer.json and composer.lock. But, it'd be better to just change the web server config.
If there's still a problem, look at any files you changed. They might have something that's printing something out inadvertently. There might be a closing PHP tag followed by whitespace. Siteground might also be running something that causes output.
I count five instances of \Drupal:
- in README.md. I don't think that should be replaced
- in a drush function. Unless that's changed to use classes, that can't be injected.
- in SourceSelectForm. I didn't inject that because getFileValidators will be reworked so the Drupal call is no longer needed once the module doesn't support D9
- in ImportWizard. I don't know if there will be a conflict with how ctools does things. If there is, this might have to remain.
- in ImageSelectForm. I can replace that.
I'll post another patch over the weekend that deals with the last two items.
I haven't tested this, but do a find for function system_status
Then, change the line to be $requirements = module_invoke_all('requirements', 'runtime'); print_r($requirements);exit;
That might show you the problem. Just make sure to change the line back.
Release it to the public and solicit feedback or pay someone (such as yours truly) to do it.
If you have *specific* concerns about a contrib module (like unsafe code you see in it), privately contact the Drupal security team: https://www.drupal.org/drupal-security-team →
If you don't have specific security concerns and it's a contrib module, what's the issue?
AFAIK, the link in my last comment is where the latest code is. If anyone wants to test it, just:
git clone git@git.drupal.org:project/wordpress_migrate.git
cd wordpress_migrate
patch -p1 < d11update-3435726-13.patch
If you clone https://git.drupalcode.org/project/wordpress_migrate the patch should apply cleanly.
I can't say that for certain because when I've used them it's been in conjunction with contrib or custom code that determines if the user has access to the file. I'd suggest just using that contrib or custom code.
Have you tried 'drush cc' and then choosing the Drush cache? You can also truncate 'cache_' tables in the db, run cron, run update.php, clear cache, etc.
Read the comments before that line of the file. You need a module that implements hook_file_download and decides if the user can access that file. I believe that'd be something like private_files_download_permission
I'm not an SEO and search engines have their own ways of doing things, but if you keep the URLs the same and avoid 404s and have the same features in the page (like site-specific metadata), it seems like that should be enough. This module might help: https://www.drupal.org/project/seo_checklist →
The design question is a little tricky since Drupal and WP themes use different technologies. If your WP theme is based on Bootstrap that would probably make it easier. If your WP theme has a lot of customizations that'd make things more difficult. There are carousels and other types of widgets for Drupal if you're using those with WP. In any case, a good CSS person should be able to make the themes look the same.
If you have a budget for this I can help you set up the site and do the migration.
Here's an updated patch. It should work with D9/D10 but I only tested D11 this time.
I can rework my patch to have the missing parts, it does work on D11.
However: the rector patch uses the backwards compatibility layer. My patch instead tests if things are available. That's not an issue if you don't want to support D9.
Should I post a new patch?
That's odd, I'll update it tomorrow. I'll also test out #5 on the other thread.
An abridged def is:
namespace Drupal\wordpress_migrate;
interface WordPressMigrationGeneratorInterface {
public function createMigrations(array $configuration): void;
}
and the services file:
services:
wordpress_migration_generator_factory:
class: Drupal\wordpress_migrate\WordpressMigrationGeneratorFactory
arguments: ['@entity_field.manager', '@plugin.manager.migration', '@file_url_generator']
Are the tags being written to the search index?
You could also have a list of tags, a tags cloud, use faceted search, etc.
This appears to be a common issue, see
https://www.drupal.org/forum/support/upgrading-drupal/2024-11-07/1036-to... →
In Twig 3.14.0 (used by a version of D11 dev), that method is just this.
I don't know if this version relies on something that's not in earlier versions, but you can always try swapping this in. If that fixes it, then try to upgrade to a version of Drupal that uses a higher version of Twig, or just make the change each time you upgrade something.
public function ensureToStringAllowed($obj, int $lineno = -1, ?Source $source = null)
{
if ($this->isSandboxed($source) && $obj instanceof \Stringable) {
try {
$this->policy->checkMethodAllowed($obj, '__toString');
} catch (SecurityNotAllowedMethodError $e) {
$e->setSourceContext($source);
$e->setTemplateLine($lineno);
throw $e;
}
}
return $obj;
}
You'll need to provide more info. What's the code around that line? What are the values of the variables involved?
Have you tried running cron, clearing the cache (if necessary, in the db), and running update.php?
Hopefully that will be clearer for non-native speakers.
It's probably a MySQL setting related to packet size, timeouts, etc.
Why not just use mysqldump?
You should post how you solved it. Did you visit admin/reports/dblog? Look in the watchdog table in the database? Look through the web server's error log?
It would help if you could indicate the classes & methods involved in a 404.
As a matter of policy you might want to rethink this. Using a VPN doesn't necessarily mean the user is up to no good. For banks etc blocking VPNs might make sense, but the reason Google/Facebook/etc look askance at them is because they want to compile dossiers on people and follow them around the internet.
What's $callback before the call to doTrustedCallback? This sounds like it could be a difference in PHP versions, but it might also be a data issue.
I was able to duplicate the issue. The patch applied and looks OK.
One question is whether using a non-existent format should thrown an exception or not. Given the use of a fallback format, it seems like the idea is that a formatted date should be returned even if a bad format is used. So, this seems OK to me unless someone suggests logging a warning the first time a non-existent format is used.
Are you saying you're getting this on a *fresh* install? If so *and* you meet all the requirements, *and* you can duplicate this and document the steps, then file this in the core issue queue.
But, since this is D10, I suspect you have some sort of... unmet dependency. You'll need to look in the server error log to find out what it is. Or, print out $invalid_default_config and $missing_dependencies in ConfigInstaller::checkConfigurationToInstall().
What are the links on admin/structure/taxonomy? It's probably not great to use URLs like taxonomy/term/%ID%, instead you'd want something more SEO friendly. But, if you want those and they aren't like that, you can write code to change them.
The mail thing is a key bit of info. If you can't get your hosting to enable mail, then you'll need to install something like maillog to prevent mail from being sent.
The issue appears to be the error. You've probably got a message with a red "X" or similar on the page I mentioned. You need to find that, or an error in your server logs.
If you have a budget for this I can look at the admin side of the site. It shouldn't take long to find the error, but fixing the error may or may not take a while.
It's probably the "unexpected error". Are there errors listed on admin/reports/dblog or in the web server error log?
There's no way to tell since you haven't provided enough info. When you go to admin/config/development/configuration/single/export and export a role, is everything listed in there available on the target site?
Can you write code to ensure the role is actually set, or use migrate_devel to show the destination?
If you write code to set a role programmatically outside the migration, does it work or throw an error?
Since others haven't added to this issue, I assume it has something to do with your environment. Can you disable custom/contrib modules one by one and see if the problem keeps happening? Some code somewhere is probably trying to store the database connection in the db or similar.
What I'd do is create a test setup with just a couple of sites and then add code that logs what the update module is doing.
If you don't get much traffic and your cache is 10gigs, I'd first figure out what's filling the tables.
Setting up Redis or memcache is straightforward. Your host might already have one of them installed, or you can do it with SSH access. But, you're going to need a lot of RAM.
I'd figure out a better way to do caching based on what's being cached.
You can also clear all the tables starting 'cache_' using 'TRUNCATE ' or similar. You might delete something someone was just using, but unless you take the site offline for a bit that can't be helped.
Feel free to close if you still don't want to resolve this.
You can duplicate this by creating a node type with a reference to media entities. Then, create a node of that type and add images. Photoswipe should work OK. Then, edit the node and add a video. You'll get the crash above.
In my case, $this->settings['photoswipe_reference_image_field'] in ImageDTO's constructor is field_media_image, but $this->getMediaSourceField($media) is field_media_video_file for the video. Thus, $media->get($photoswipe_reference_image_field); crashes.
It's easier for me to just add a separate video field to my node type, but you might want to skip media types that you aren't expecting.
Why delete the node at all? If Hoarding: Buried Alive has taught us anything, it's that we should Just mark it with some special sign (like a 'Not completed' term) but keep it around so you have a record
[Copying from the since closed "Hiding the node title makes node form submission crash 🐛 Hiding the node title makes node form submission crash Active "]
It seems to me that everything should have a title, even in the case of a "Person" object. The title could be random, or constructed from something else, but you should always be able to count on an existing entity having a title of some kind just as you can count on it having an ID.
Also, I don't think handling this at the form level would be a good idea since someone might hide the title and then have custom code or a contrib module that provides the title. Preventing them from hiding the title would cause problems for them. If you let them do it but instead show a warning that would annoy people who know what they're doing and confuse others.
I suggest changing SqlContentEntityStorage::mapToStorageRecord to throw an exception if a field is required but empty. It already throws an exception in one case throw new EntityStorageException("Table mapping contains invalid field $field_name."); so adding a check in the same area doesn't seem out of place. You're going to get an exception in any case, it might as well give the user a clue what the problem is.
The problem you're talking about isn't clear enough, but for such cases you can try to access a file like README.md. Adjust your web server settings or file permissions until you can read that in the browser.
Is bootstrap_layout_builder installed and enabled?
I had this issue on Drupal 11.0.4 and it was because there was no language.entity.en config entity. There were such entities for various other languages, just not en. I have no idea how that happened.
Just because it might mask an underlying issue is no reason not to make the updateLockedLanguageWeights method more bulletproof.
I've attached my attempt to do that based on D11 dev of Oct 18, 2024.
Please send me an email via my profile here and I'll reply. I'm on Pacific time.
You might be able to export the config files and change the names in them and then re-import them. Or you might be able to run search-and-replace db queries but those might not work if serialization is involved. Or you could write a script to load everything in the db, change names, and write it back.
But, it's probably going to be easier to just do a migration. You can export your data to JSON using views (including custom fields, image paths, etc) and then migrate them in.
This shows how I structured it: https://github.com/TolstoyDotCom/migrate_json_test I should add a note that it expects the module to be in the modules/custom directory.
Drupal should avoid getting into political issues. That means removing the Ukraine banners, asking people what race they are, DEI initiatives, etc etc. This site and the software should be neutral.
You illustrate a problem that happens by not being neutral: now they have to come up with an explanation for why they'd support one issue over another.
There are plenty of other sites that are willing to take stands on issues.
I worked with that a while back but I forget the specifics. IIRC it wouldn't let you add something to the cart if it was out of stock and I had to add code to deal with things that could be backordered. I'm available for consulting if you don't figure it out.
It seems to me that everything should have a title, even in the case of a "Person" object. The title could be random, or constructed from something else, but you should always be able to count on an existing entity having a title of some kind just as you can count on it having an ID.
Also, I don't think handling this at the form level would be a good idea since someone might hide the title and then have custom code or a contrib module that provides the title. Preventing them from hiding the title would cause problems for them. If you let them do it but instead show a warning that would annoy people who know what they're doing and confuse others.
I suggest changing SqlContentEntityStorage::mapToStorageRecord to throw an exception if a field is required but empty. It already throws an exception in one case throw new EntityStorageException("Table mapping contains invalid field $field_name."); so adding a check in the same area doesn't seem out of place. You're going to get an exception in any case, it might as well give the user a clue what the problem is.
Provides additional functionality for Drupal's migration system. Use this module if you need to migrate from JSON files, replace parts of strings, get fields from an existing entity, and much more.
This is like an archeology dig. You should migrate to D10/11 if possible.
The first set of warnings were resolved in the version you upgraded to: https://www.drupal.org/node/3298593 →
You should try to upgrade your PHP if possible. I don't know how high you could go with D7 and your modules, but try to get to PHP 7 if you can. Even so, I believe only PHP 8 versions are still supported.
error_log shouldn't be inside your web root, that's a security risk: hackers might be able to get useful info from it. In any case, it will contain different messages than dblog: error_log comes from the web server, dblog messages come from Drupal. In dblog, just look for messages marked in red. You can filter things by severity. There's also a setting letting you change how many dblog messages are saved.
Re the comments about Nestle above, now do Margaret Sanger.
For future reference, this explains how to troubleshoot clean URLs not working:
https://www.drupal.org/docs/administering-a-drupal-site/troubleshooting-... →
Only you can answer that question, but it's not that difficult to move a Drupal site so you could start on your local computer or on temporary hosting like AWS or Azure.
I think you're referring to a feature that was removed pending a better version.
In the meantime, you should look into using composer: https://www.drupal.org/forum/support/post-installation/2024-10-07/instal... →
Please search how to post an issue, since that's not much help. Are you talking about admin/modules? If not, what's the path? What happens? Are there any error messages on the page, anything listed on admin/reports/dblog, anything in the web server error log?
Maybe it installed to SQLite. If you can duplicate this using the dev version of D11, then post about this to the core issue queue.
If your host gives SSH access, using the command line as was suggested (using AI for tips) is fairly easy. You just have to be careful and make a backup.
To make it easier (albeit less secure), ask your host to let you access SSH using a password instead of a key file. Also ask your host for the full path to the root of your site (where the composer.json file is). All you need is cd [that path] followed by the composer command.
The clue to cron is probably either at admin/reports/dblog or in the web server error log (which your host can direct you to if necessary).
No one can answer the first question without looking at the site, but you can install the devel_themer module and it might show you where the spurious elements are coming from. Switch to another theme to see if it's a theme or a module issue. Disable all blocks to see if it's one of those. Disable non-essential modules to see if it's one of those. In the worst case, grep the source and change the names of things (like "page-wrapper2") to help you spot where it's coming from.
I added the missing 2 lines in but it looks like I was using an earlier version and it's now fixed. So this can be closed.
While I'm here, a documentation-related issue is that instances of getRaw( should be changed to getRawOutput(.
Another issue is that in ModeratePreRequestEventSubscriber::moderatePreRequest, $this->getConfig()->get('moderations') can return NULL and I added a line to make it an empty array in that case, but that might mask a deeper issue.
tolstoydotcom → created an issue.
I ran into this with a copy of D11 dev that I downloaded a few weeks ago. I installed the ai module and several of its submodules at the same time, including experimental modules. I assume the issue was because of ai_translate. I only had the default language installed. The error I got was: Uncaught PHP Exception TypeError: "Drupal\\language\\LanguageNegotiator::updateConfiguration(): Argument #1 ($types) must be of type array, null given, called in /web/core/modules/language/language.module on line 321" at /web/core/modules/language/src/LanguageNegotiator.php line 306, referer: admin/modules/list/confirm-non-stable
When I went to admin/config/regional/language/detection as #34 suggests, I got another error: Uncaught PHP Exception TypeError: "in_array(): Argument #2 ($haystack) must be of type array, null given" at /web/core/modules/language/src/Form/NegotiationConfigureForm.php line 141
The problem is calls to $configurable = $this->languageTypes->get('configurable') and $configurable = $this->config->get('configurable') can return NULL. When $configurable is used in in_array etc it results in those errors.
Unless that return value shouldn't ever be null and there's a more fundamental problem, it seems like the solution is to follow those calls with $configurable = $configurable ?? []; or similar.
I just ran into this when cloning a 10.3 site. I copied a db dump of the existing site into a new database and truncated the cache tables. It probably didn't help that I was running PHP8.2, but after switching to PHP8.3 I got this error.
I resolved it by running drush eval "drupal_flush_all_caches();". However, since this is such a common error perhaps throwing the exception should be made optional, or stopgaps should be used. That might at least keep some sites online while the problem is found.
Re #36, I assume that's a reference to Drupal\Component\Annotation\Doctrine\StaticReflectionParser::parse(). That uses Doctrine\Common\Annotations\TokenParser which is basically a wrapper around token_get_all(). However, there's an important note in the latter file explaining why they call token_get_all() a second time. Maybe that has something to do with it. Or, maybe token_get_all() is getting confused. The next time this happens, maybe someone could test it by adding whitespace before the '#[' of the plugin that isn't being found. Maybe PHP is getting confused by an immediately preceding regular comment or something like that.
Isn't this a case of "it hurts when I do that/so stop doing that"? I don't know if it's still an issue, but having a theme and a module with the same machine name also resulted in conflicts. Is there a check for that now? Not everything can be checked.
Maybe this could just be put into documentation.
In the existing code, I'm not clear on why it's $raw_term->parents[0] == 0 instead of just !$raw_term->parents[0] or similar. Does $raw_term->parents always exist and is it always an array? If $raw_term->parents[0] is NULL or "", is that equivalent to being 0 or does it always have to be a number? What if it's "0"? For the change, it seems like farming the checks out to other methods or a library would be better. Either of those could check if $raw_term->parents[0] exists and has a number or something else.
First, that's an old settings file, the newer ones use "[]" instead of "array()".
Second, while that file doesn't have an error, it also includes settings.local.php without checking if it exists. That should be fixed. And, the error might be in that file.
I suggest you use a more recent settings file and just copy the database/hash salt info in. I also suggest looking at the end of the file you posted and take preventative action.
It's probably easier to create media entities using the process I outlined.
First, unless you have *lots* of content, it might be easier to export the D7 site to JSON and then import that. You can more easily pre-process the JSON file than changing things coming out of the db.
What I've done is create a file entity from the images, and then create a media entity from the file entity. This or another page at their site might have more info: https://understanddrupal.com/lessons/migrating-files-and-images-drupal/
But, are you saying you don't want to create media entities? If so, why?
The accordions and 'Read more' buttons aren't going to work when printed.
You've probably got a print template somewhere and you can modify that. But, what might be easier is to just create a new, basic page as you want it, and then print that out.
Open a command line and run php -l [full path to settings.php]
Do you get the same error? Maybe you're using the wrong settings.php file.
Temporarily remove the comments to make it easier to see. Replace the whole $databases bit with this and see if that command still gives an error: $databases = [];
Look for any hidden special characters, like copying the whole file into a basic text editor and saving that as the new file.
If there's still a problem, upload the actual file (without the password).
I tested this with D10.3.5 and Drush 13.2. I was able to visit content and admin pages after enabling that module with Drush. I didn't see any issues.
If you start a new site with 10.3.5, does this still happen? Maybe it's just a problem with the site you tested with.
MigrateExecutable::import calls checkRequirements() on the migration and stops the import if it throws an exception. One option would be to add something else in that method but just have it post a warning.
However, maybe a separate service that takes a yml file and runs it through a series of tests might be better. That would help debug issues with the file. Each test could be a plugin: a ClobberedSubfield plugin, one that checks if the source file exists, is readable, and has real data, etc.
I've updated the module to D11 and kept D9 and D10 compatibility. I did one of the backwards compatibility issues differently than rector and found another similar issue. I lightly tested it on D9/D10/D11. The two methods I added at the end of SourceSelectForm can be changed once D9 is no longer supported.
I and someone in the Slack channel (https://drupal.slack.com/archives/C226VLXBP/p1726971471014629) had a problem where the protocol of the uploaded file was set to 'public://', but that wasn't resolved to 'http://'. I assume it was resolved in the past but behavior changed somewhere. I didn't look into that, I just changed the code to resolve the URL.
I also made a factory to create instances of WordPressMigrationGenerator and made that factory a service.
Patch attached.
tolstoydotcom → created an issue.
Did you add the line to set the value to the end of settings.php? If not, could something later in the file have overwritten it? Do you have multiple settings.php files? Does setting other values work?
I think I know your problem: you're using the Red X version of Drupal.
Maybe you installed a module that depends on Groups, you'll need to uninstall that first.
Otherwise, try running cron, clearing caches, and running update.php a few times, maybe a group is cached somewhere.
If all that fails, you could reduce the Groups module down to just its info.yml file without dependencies. That might crash your site if something depends on it so you might need to provide a dummy service or similar. Doing that might make it possible to uninstall the module.
I changed the repo to match what I assume you were doing before and I didn't see a problem.
If you want to post a pull request that shows the problem I can try that, otherwise it looks like this was just a temporary problem.
What I'm talking about is at a lower level.
For instance, the iris dataset has 150 lines like these, where the four numbers are measurements of the iris and the string is the type of iris. You run it through Weka which creates a model, and then you can feed new measurements (like 1,2,3,4) to that model to get its guess of the type:
5.1,3.5,1.4,0.2,Iris-setosa
7.0,3.2,4.7,1.4,Iris-versicolor
6.7,2.5,5.8,1.8,Iris-virginicaAnother model takes someone's weight, number of pregnancies, glucose level, etc and predicts how likely they are to become diabetic.
Is there a place in this system for things like that, or is it mostly at a higher level?
Is this the same as Weka classifiers? For instance, the iris dataset which takes four floating point numbers with plant measurements and returns a string indicating which type of iris it likely is: https://archive.ics.uci.edu/dataset/53/iris
If so, I posted an open source helper library to Github designed to make it easier to deal with Weka: https://github.com/TolstoyDotCom/aiaiai
If there's enough interest and I can get Java <-> PHP communication working, I could provide a module that uses your API or that provides a simple API.