🇺🇸United States @TolstoyDotCom

tolstoydotcom → changed the visibility of the branch 3495351-change-permissions.yml-files to hidden.

For a personal D10 site, I created a new view in my local version that I tried to import into the live site. I got this message: "Configuration block.block.workflowtransitionform depends on the theme that will not be installed after import."

I exported that config and it had this:

...
dependencies:
  module:
    - workflow
  theme:
    - null
id: workflowtransitionform
theme: null
...

I replaced both instances of "null" with "claro", imported that config on admin/config/development/configuration/single/import, and then I was able to import the view.

I have no idea where "null" came from, but if this is a common problem for a lot of people it might be easiest to create a "config repair" contrib module that would look for and fix such things.

My concerns, as usual, were shot down in the Slack thread.

Maybe recipes have a fundamental flaw in that versions are given. I.e., someone might be using an older version of a module for a specific reason and that older version would work with the recipe if it were flexible. Perhaps a more adaptive system would be better, like something that would try to match what the site has installed currently.

I posted this, please follow up there and then summarize here:

https://drupal.slack.com/archives/C2THUBAVA/p1742485267633119

There's no direct upgrade path from D7 to D8+, you have to do a migration. See "31 days of Drupal migrations" for a lot of background info. Or, if you have a budget for this you can hire someone such as myself to put that together for you.

Another possibility is file permissions. Maybe the web server can't read one of the files.

It'd be great if someone could add debugging code to Doctrine\Common\Annotations\TokenParser that prints out what it's parsing. My rawdebug file can be used for that, or just error_log. Of course, merely adding debugging might change the files in such a way that the problem goes away.

You can try this:  https://www.drupal.org/project/redis →

I don't use ddev so what I'd do in this case is switch to a local LAMP install. In any case, you could backup everything, delete the vendor directory, truncate the 'cache_' tables in the db, and then run 'composer install'.

Note that using ddev means you can update code files through the Drupal UI. However, if you try that using LAMP on a server it would require unsafe permissions or ownership: on public sites having the web server being able to write to code files is a huge security risk.

You'd need to scan all of the text fields for all of the content types looking for absolute or relative links. There might be such a module (like a reverse sitemap) but most likely you'd need to code it up. If you aren't a coder and you have a budget for this, feel free to DM me.

See the FileItem.php file. You'd probably need to alter anything where FileItem::validateExtensions is used, to replace it with your own more permissive method.

You'd want to disable caching and add a cache buster to the URL. If that isn't it and there are no error messages on admin/reports/dblog or in your web server error log, then add code to the code that checks access to find out what the problem is. You can also install a debug module that shows that info.

To be clear, my module adds a Javascript file to the PB page. That JS file adds download buttons to eligible modules. That works on the first page, but if I click the pager to go to Page 2, Page 3, etc my Javascript isn't run: the attach method isn't called.

It seems bad design to have something in Drupal that isn't extensible: everything else is. If you add JS to a Views page, the JS's attach method will be called when you go to Page 2 etc.

My workaround is to poll every two seconds and add my buttons if they haven't already been added. That's suboptimal but I can deal with it if necessary.

Like I said, I'm not familiar with Svelte, but is adding in a hook or calling Drupal.attachBehaviors out of the question? Feel free to close again if that isn't going to happen.

What *I* would do is use my rawdebug module to print out the statement involved. Line 113 is $return = $this->clientStatement->execute($args); and it says For a \PDO client connection, this [clientStatement] will be a \PDOStatement object. And, there's a PDOStatement::debugDumpParams . The last one that's printed will be the culprit. I'd then look into indexes, how much data there is, etc.

I'm not familiar with Sharepoint but it looks like a Dropbox alternative, not a way to build web sites. What do you want to do? Is this a one-time export, or an ongoing thing?

Did you grep all of the source for the version with periods? 

jsonapi.search_page

If you can't find it there, can you export your config files (either through the UI or drush) and look for it there? If that still doesn't work, see if it's in your config or key_value tables. Those might require queries that cast binary to char.

Once you find it, do a db backup and then delete it.

Assuming $databases in settings.php isn't commented out or being overwritten by something else later in the file or in an include file, do you see the expected info when you add this to Database.php at the start of the getConnection method?

echo '<pre>';print_r(self::$databaseInfo);exit;

Also here:  https://www.drupal.org/project/drupal/issues/3508236 💬 Parameter "entity" for route "jsonapi.block--block.individual" must match "[^/]++" ("" given) Active

If you search the source code, where is jsonapi.search_page mentioned?

+1 on adding the link to /forum back. The Stack sites are a great resource, but it's best to have help on this site. The Slack channel should be more for ephemera.

tolstoydotcom → created an issue.

Whatever the status of https://www.drupal.org/project/drupal/issues/3372939 🐛 Use AccountProxyInterface instead of AccountInterface Needs work , the only method this module calls on AccountProxy is hasPermission and that's in AccountInterface. So, in the issue fork I changed AccountProxy to AccountInterface. There appears to be crosstalk with the other issue fork I created so I can do this again if needed.

tolstoydotcom → created an issue.

It's probably a problem with the subdomain not being set up properly. I suspect Drupal thinks it's installed under some other domain. I'd press F12 and try to figure out where Drupal is trying to load things from. If you can, test it without a subdomain.

tolstoydotcom → created an issue.

I'd be very surprised if CMS won't run on Wampserver, XAMPP etc as long as you have the correct versions of MySQL, PHP, and Apache. Drupal is just a (very large) PHP application, it doesn't embed itself into your system or anything.

Why not try it out and see? Just make sure you've got composer installed and the root of the site contains a 'vendor' and a 'web' directory, serving Drupal out of 'web' should work.

I reopened this because it still seems to be an issue: https://drupal.slack.com/archives/C1BB308HH/p1737753467044569

In the current version of the flag module, there's FlagLinkBuilderInterface::build($entity_type_id, $entity_id, $flag_id, $view_mode = NULL); defined in https://git.drupalcode.org/project/flag/-/blob/8.x-4.x/src/FlagLinkBuild...

However, the current version of this module's FlagAnonLinkBuilder::build is missing the last argument. I'll add a MR.

I've run D7 on wampserver and XAMPP. As posted above, I've also run it on plain apache2+MySQL. I hesitate to say composer isn't even a strict requirement because the reality is that you're going to have lots of problems if you can't use it. Opening a terminal & typing in two commands (one of which is provided for you) shouldn't be too onerous for most people.

marcus_johansson → credited tolstoydotcom → .

Look up the Drupal Slack channels. You want the project-browser channel.

IMNSHO, Project Browser encourages an unsafe installation. I'm working on a safe alternative and I'll announce it there and on Reddit. It'll take some time.

They haven't made it clear enough, but "Drupal Core" and "Drupal CMS" are basically the same thing. CMS just has pre-installed modules and recipes.

Not to further confuse things, but see the "dangerous" part: https://wisdomtree.dev/drupal-cms-review

Someone else had the same problem recently:

https://drupal.slack.com/archives/C1BB308HH/p1737368679086469

Before I knew about this issue, I suggested this:
It would help if you could edit drupal_check_module(). Just before the "addError" line, add this:
echo '<pre>';print_r($requirements);exit;
Then, post what it prints. It might warrant a bug report somewhere.

Even if the module is missing dependencies, it doesn't seem like drupal_check_module() should be doing this.

Drupal runs fine if you just install MySQL (or even Postgres) and a web server (Apache2 is easier; if you use nginx you'll need to find a config file).

It doesn't really require that, it just doesn't highlight alternatives.

I'm on Ubuntu and instead of ddev etc, I just use apache2 + MySQL. Apparently Ubuntu can be installed on Windows so that's an option.

I'm currently working on a way to make dealing with composer easier for non-devs.

If you use section names like "admin >> editing" and "admin >> deleting", it will look like a hierarchy.

Or, sections can be nested (the client would have to be aware of that of course):

sections:
  - title: users
    weight: 1
    extended_help: 'permissions for regular users'
  - title: admin
    weight: 2
    extended_help: 'permissions for admins'
    sections:
      - title: editing
        weight: 1
        extended_help: 'permissions for admins editing items'
      - title: deleting
        weight: 2
        extended_help: 'permissions for admins deleting items'

I don't have an answer for that, but I didn't mean for you to make my change permanently. "Don't hack core" is an old maxim around here. What's $plugin_id?

I pushed the changes/additions if anyone wants to review them. I made a minor change to the existing file core/modules/user/src/PermissionHandler.php and a few changes to core/modules/user/user.services.yml (I added comments for those).

There are now three ways to get permissions:
- the 'user.legacy_permissions' service. This is the current way.
- the 'user.permissions' service. This is a replacement for the former way.
- the 'user_permissions_parser.repository_factory' service. This is what new code should use, it returns an object with all of the permissions.

There are differences in the sorting between the first two services above. If that's an issue I can change it. However, both get the same permissions.

I can add tests if this looks OK.

The code in question:

   if (isset($definitions[$plugin_id])) {
     return $definitions[$plugin_id];
   }

What I'd do is use my rawdebug module and print out what's in $plugin_id and get a stack trace. At least add echo (string) $plugin_id;exit; and let us know what it says. A quick fix is probably to replace $plugin_id with (string) $plugin_id in both places but I'd only do that if I thought it was just a matter of having to clear the cache or similar.

You could write a script to run composer commands over the web, but that would be very unsafe: you'd basically be installing a tool (a shell) that hackers try to install on your site.

cPanel has a shell but that depends on your host.

Drupal could work with cPanel and similar to help people like you, but my suggestion to do that has been unilaterally ruled out: https://www.drupal.org/project/drupal_cms/issues/3491208 ✨ Create installation recipes that cPanel & hosting providers can use Active

The alternative is to work on your site locally and then upload it to your hosting. ddev is one option, but I just use local apache2 and mysql installations. I'm on Ubuntu so this is a lot smoother than Windows.

I might be and probably am wrong, but that trace doesn't offer a good clue. Are you able to export the config files using either the UI or drush? Is that route in those files somewhere?

If you can answer that and post this to the core issues queue they might be able to spot something.

An idea I have is some sort of "safe mode" for Drupal that would provide replacement versions for files that, instead of throwing exceptions, return anodyne data where possible (as with the help route in my previous suggestion).

Can you help find out the reason?

- make a backup of RouteProvider.php

- change line 211 to echo '<pre>';debug_print_backtrace();exit;

- post the result (use a storage service since it'll be a huge file)

Then, undo those changes and change line 211 to return $this->getRouteByName('help.main');

Then, clear caches/run update.php/run cron a couple times to see if that solves it.

Note: If you can avoid doing the last until later it might be helpful since there might be other things you can do to figure out the problem.

Every contrib module has the necessary composer command. The other main one you need is 'composer update'. If something goes wrong, there's a composer forum here.

If you can find the cause of the WSOD that would help. What does it say on admin/reports/dblog?

I did 'composer update' and uninstalled AI Search. All I get for admin/config/ai/explorers/vector-db-search is a 404 and there's no route with vector-db-search in the current code. I didn't see the strings in my changes in the current code either. Since I haven't been keeping up on all of the intervening commits, what are the steps I should be testing?

Assuming this is just a temporary issue that a cache clear + cron + update.php will solve, then you can temporarily replace the given line with this: return $this->getRouteByName('help.main');

Note that that could cause an infinite loop.

It'd be better if you can find out what's looking for that route by calling debug_backtrace().

I did as #6 suggests.

No matter how it's presented, augmenting permissions files seems like it's going to be necessary for new users. Should I create a patch? If so, should it be based on the current module, or based on using plugins for each of the additions to the permissions files. Those plugins would have a weight so the heaviest plugin would do what currently happens: everything is assumed to be a permission. Each plugin would get an array derived from the permissions file and the plugin would indicate in that array if what it's processed.

https://www.drupal.org/project/tokenuuid → isn't unmaintained, I just pushed a D11 version. I was waiting on https://www.drupal.org/project/tokenuuid/issues/2928359 📌 Why is this not a patch for Token? Postponed but when this patch is backported I assume tokenuuid can be marked as not needed.

Thanks, but this module is going away since the dev version of D11 has the same functionality. That will eventually be backported.

I updated it for D11. However, bear in mind this module is going away since the dev version of D11 has the same functionality.

tolstoydotcom → created an issue.

I'm sure there's a way to do this with Views, but the quicker option might be some custom code. Another option is to denormalize the data, like give City text fields for Country and Continent and then populate those when a City is created.

It's good you found the problem. Can you repost your solution to https://www.drupal.org/project/issues/opigno_module → ?

There's a D10 version of tb_megamenu. If that's already installed they might have changed the name of their entity type. You might need to do some database surgery or use a module that lets you change machine names (if there is such a thing).

The missing field can be added, but you'll then need to import the data for it.

I can't help with CSS issues but those on Fiverr might be able to help.

To find out what the 500 error is, look in admin/reports/dblog. It's probably related to the missing field or similar.

I don't know why you're changing the directory name. While it's probably not related, do you still have the problem if you don't do that?

Can you add debugging code to find out what's generating the redirect? Like adding debug_print_backtrace() in the file you mentioned.

What errors are you getting? Don't they give you some ideas as to what needs to be fixed?

If you have a budget for this you can hire me or someone else to do this for you, otherwise you should ask to determine if the errors can be easily fixed or if they indicate serious problems.

All I see is a red "X". First you need to find out how ads are being served. An external service, or from Drupal itself? If the latter, look through admin/content or admin/structure/block to see if you can find it. If your org has a budget for this, you can reach out to me or others here for paid help with such issues.

This works with D10: https://www.drupal.org/project/give →

There are also donations add-ons for Commerce.

Or, if there's a D7 donations module you prefer and you have a budget to make it D10 compatible, feel free to DM me.

Disable unnecessary modules and use different themes to try to isolate where the problem is coming from. If there's custom code anywhere, disable that. Then, if there's still a problem, file this as a bug report for that specific project.

FYI, I'm proposing adding new keys to permissions.yml files that would add help text and divide permissions into sections:

https://www.drupal.org/project/drupal/issues/3495351 ✨ Make the user permissions page less daunting for new users Active

These two issues are related, but this issue concerns the UI and mine mainly concerns the files.

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... →

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.