Budapest
Account created on 8 March 2007, about 18 years ago
#

Recent comments

🇭🇺Hungary danyg Budapest

Also I can confirm, I was able to render the title by adding the {{ content.title }} by using the patch #39.
Of course, the Title field was enabled on Manage Display.

🇭🇺Hungary danyg Budapest

Today I tried to update another site where data, entity, entitycache, entityconnect, entityform, entityreference, and some other entity* modules are installed. This time I didn't face any issues, clearing cache on th UI or by drush works like a charm.
I'm going to update the other site I reported 8 months ago to see whether the issue still persists there.

🇭🇺Hungary danyg Budapest

Here is the updated patch which is compatible with the latest, 7.101 Drupal version.

🇭🇺Hungary danyg Budapest

Thanks, the patch make the delete function work. Marked as RTBC.

🇭🇺Hungary danyg Budapest

Sorry, wrong patch in my previous comment. So, this fix is for 7.x-1.x users.

🇭🇺Hungary danyg Budapest

And this patch will help for those who still use 7.x branch of this module and has an updated library.

🇭🇺Hungary danyg Budapest

I can confirm that the patched version fixes the issue on enabling the module. Thanks!

🇭🇺Hungary danyg Budapest

My approach was here that the node.module's _node_query_node_access_alter() function has a bad assumption with the field. It assumes that field name to check is "nid" always. But if we use the entityreference module, the referenced field will be entity_id. So, my patch checks if the base_table contains "field_data_" or "field_revision_" string, the referencing field will be entity_id.
I tried to catch the point where I'm able to alter the subquery in the scope of entityreference.module after the node.module adds the wrong query to it, but I wasn't able to do (since both have the same weight in the system table and entityreference's query alter executed earlier).
So, it's not the perfect solution, but it fixed the unknown column issue for me.

🇭🇺Hungary danyg Budapest

I have the similar issue after upgrading a site from Drupal 8.9 to 10.2
It didn't throw any error until I upgrade from 9.5.11 to 10.2.0

PHP Fatal error: Declaration of Drupal\commerce_price\Repository\CurrencyRepository::get($currency_code, $locale = null) must be compatible with CommerceGuys\Intl\Currency\CurrencyRepository::get(string $currencyCode, ?string $locale = null): CommerceGuys\Intl\Currency\Currency in /app/web/modules/contrib/commerce/modules/price/src/Repository/CurrencyRepository.php on line 44

This error came up when system_post_update_timestamp_formatter() update should be executed. Still checking what's wrong.

🇭🇺Hungary danyg Budapest

@Mehrdad201 you don't need to patch the v1.2 release with thi patch. The mentioned patch had been created in 2021 and the latest stable release uses a different approach and you don't need to use this patch. I would strongly recommend to upgrade your PHP at least to 7.4 if you have chance to do this. That will make a big performance impact, I believe.

🇭🇺Hungary danyg Budapest

Here is the updated patch, extending the last patch (#7), adding the suggested reminders to administrators.
Now it warnings the admins if the "Background rebuild" is disabled and also notify admins to run rebuild process when a user is being updated and the automatic rebuild is turned off.

🇭🇺Hungary danyg Budapest

It's a simple and super solution for the issue, thanks. I can confirm the patch works when you translated the authenticated and/or anonymous role's name. Changed to RTBC

🇭🇺Hungary danyg Budapest

See thread at https://www.drupal.org/project/adminimal_admin_toolbar/issues/3285987 📌 Automated Drupal 10 compatibility fixes Fixed

🇭🇺Hungary danyg Budapest

Today I run into a similar issue (although I have good experiences with Boost on other sites) and I had to uncomment the following lines in the .htaccess to make the admin functionality work

  # Caching for anonymous users
  # Skip boost IF not get request OR uri has wrong dir OR cookie is set OR request came from this server OR https request
  #RewriteCond %{REQUEST_METHOD} !^(GET|HEAD|POST)$ [OR]
  #RewriteCond %{REQUEST_URI} (^/(admin|cache|misc|modules|sites|system|openid|themes|node/add|comment/reply))|(/(edit|user|user/(login|password|register))$) [OR]
  #RewriteCond %{HTTPS} on [OR]
  #RewriteCond %{HTTP_COOKIE} DRUPAL_UID [OR]
  #RewriteCond %{ENV:REDIRECT_STATUS} 200
  #RewriteRule .* - [S=2]

And I updated my .htaccess to work for anonyms like this:

  # NORMAL
  RewriteCond %{REQUEST_METHOD} !^(GET|HEAD)$ [OR]
  RewriteCond %{HTTP_COOKIE} !DRUPAL_UID
  RewriteCond %{DOCUMENT_ROOT}/cache/%{ENV:boostpath}/%{HTTP_HOST}%{REQUEST_URI}_%{QUERY_STRING}\.html -s
  RewriteRule .* cache/%{ENV:boostpath}/%{HTTP_HOST}%{REQUEST_URI}_%{QUERY_STRING}\.html [L,T=text/html]

I spent many hours with debugging, I know this is not an optimal solutions (I wasn't able to figure out what's wrong here), but this was my workaround.

🇭🇺Hungary danyg Budapest

I made a minor upgrade since I found another deprecation:
Deprecated: Optional parameter $prefix declared before required parameter $form_values is implicitly treated as a required parameter in /app/docroot/sites/all/modules/contrib/import_html/import_html_ui.inc on line 1715
After a little examination, I realized that $prefix doesn't need initial value among parameters, so I removed.

🇭🇺Hungary danyg Budapest

At first sight, it looks good, the errors has gone on the site I was facing with the same issue.

🇭🇺Hungary danyg Budapest

Hi, I have EntityMalformedException "Missing bundle property on entity of type file" since I updated one of my sites to 2.15.
I checked the changes of the latest stable release and I found out that the error is gone if I comment out the features_ctools_plugin_api_alter() function.
I wasn't able to figure out yet what was wrong with this function, but this is the point where we could start to debug.

🇭🇺Hungary danyg Budapest

Hi, I'm adding an improved patch of the #6, since I was still getting error after applying the patch.

🇭🇺Hungary danyg Budapest

Thanks for the patch, I can confirm that errors have gone after applying the patch. Set to RTBC.

🇭🇺Hungary danyg Budapest

changed to the latest release

🇭🇺Hungary danyg Budapest

according to the last 3 comments, I changed to RBTC. Thanks for testing!

🇭🇺Hungary danyg Budapest

Hi, I got several PHP errors with the patch #12, I fixed the issues (duplicated "return") and replace non-existing "extension.path.module" to "extension.list.module" service

🇭🇺Hungary danyg Budapest

Hi @drw, we introduced a new permission (rebuild node access permission), you need that permission to reach the admin page.

🇭🇺Hungary danyg Budapest

Hi, here is a Drupal 10 compatible patch for the latest RC2 release

🇭🇺Hungary danyg Budapest

patch attached.

🇭🇺Hungary danyg Budapest

danyg created an issue.

🇭🇺Hungary danyg Budapest

Hi there,

I'm also suffering with the continuous alert, so here is the solution.

- It does not affect all the nodes on the site, only the ones which were created/owned by the modified user(s)
- It collects the records to a separate table and will rebuild their permission
- It defines an admin interface where admins can set to update permissions during cron jobs (admin interface defines new permission)
- It doesn't trigger the node_access_needs_rebuild() since that call would update all nodes
- Admin can run the rebuild permission batch process manually, but it only updates the affected nodes

I hope it helps.

🇭🇺Hungary danyg Budapest

Thank you! Actually, PHP 5 is not a supported engine already at most hosting providers, but it still exists (usage statistics around 1%). Progress is cool, but since Drupal 7 still supports PHP 5.x (see https://www.drupal.org/docs/7/system-requirements/php-requirements-for-d... ), the module's 7.x version should respect it.

🇭🇺Hungary danyg Budapest

Sorry guys, but this patch doesn't make sense to me.
It returns an almost empty array (with theme information) and doesn't render any messages on the website.
When this it called from blockify_get_content() function it should contain a renderable array or a rendered output. For now, it contains only
array('#theme' => 'status_messages') which results an empty output.
For those whom face with the same issue here is a revert patch.

🇭🇺Hungary danyg Budapest

@SaIAG it's very strange, it looks that applying the patch wasn't successful for you and it caused a parse error.
The error comes from the same file but from an earlier point. Have you already applied a different patch on this module?

🇭🇺Hungary danyg Budapest

@psaleks Can you set the status to RTBC (Reviewed & tested by the community) if it looks good to you?

🇭🇺Hungary danyg Budapest

Ok, here is an improved patch for this issue. It now respects if there is more than one bundle are being used in the reference field (like listing all pages and stories)

🇭🇺Hungary danyg Budapest

It's a duplicated issue, patch is available at https://www.drupal.org/project/entityreference/issues/3349989 🐛 Field reference do not use order (asc,desc) that done in views reference Fixed

🇭🇺Hungary danyg Budapest

It looks duplication of https://www.drupal.org/project/url_redirect/issues/3135964 🐛 "Negate the condition" not working RTBC

🇭🇺Hungary danyg Budapest

Patch at #7 works properly.

🇭🇺Hungary danyg Budapest

@cpa2client with the latest stable release we don't need to override the theme_image in the theme's template.php. Boost shouldn't have an effect on rendering. Can you add more details about your problem?

@dmundra I can confirm that the patch was merged and the current stable release (7.x-1.2) contains most part of it. Can you add more details about your issue?

I added a patch for Views integration for the most common Image formatter, so if it came from Views pages, you can give it a chance.

🇭🇺Hungary danyg Budapest

Here is the patch that makes the Views' simple image formatter work. Since the Views uses the field_view_field() and doesn't use the hook_preprocess_field, I added an implementation of hook_field_attach_view_alter() which is invoked within field_view_field() function.

As an admin, you need to choose the Image formatter and tick the "Webp support" checkbox to make it work.

We should improve it by handling the other formatters as it is written in https://www.drupal.org/project/imagewebp/issues/3226638

🇭🇺Hungary danyg Budapest

Ok, I realized that the latest patch (diff) wasn't applied properly. I created a new patch from it and now it can be applied properly and fixes the notices that I mentioned before. So, it seems the changes in #7 are good, I had trouble only with the format. Actually, I would put it to RBTC since the logic looks good, but I change it to Needs Review again to have somebody test the patch.

🇭🇺Hungary danyg Budapest

Thanks, I tested the latest patch. It resolves the initial notice, I found some new with the latest patch:

Notice: Trying to access array offset on value of type null template_preprocess_tb_megamenu_item() függvényben (/app/sites/all/modules/tb_megamenu/tb_megamenu.themes.inc 86 sor).

Notice: Trying to access array offset on value of type null template_preprocess_tb_megamenu_subnav() függvényben (/app/sites/all/modules/tb_megamenu/tb_megamenu.themes.inc 296 sor).

Warning: array_multisort(): Array sizes are inconsistent tb_megamenu_insert_tb_item() függvényben (/app/sites/all/modules/tb_megamenu/tb_megamenu.functions.inc 441 sor).

I try to check these issues later, but now I set it "Needs work", since it doesn't seem perfect yet.

🇭🇺Hungary danyg Budapest

Thank you for the patch, it fixed the problem. For some reason the patch cannot be applied automatically (for me, but I was able to apply it manually).

🇭🇺Hungary danyg Budapest

Hi there, well the patch was written 2 years ago and we have updated releases on this module since then.
I haven't checked the latest one yet, but I'm planning it - hopefully - soon.
@cpa2client in https://www.drupal.org/project/imagewebp/issues/3057526#comment-14072706 🐛 WebP images not rendering on the front-end Fixed I added the trick to override the theme_image implementation in your theme, is it possible that this is missing from your code and does it lead to your issue at the front-end?

🇭🇺Hungary danyg Budapest

Thanks for the patch, it works properly. I added the same logic to the boost_mobile module's hook_flush_caches() implementation and it worked as expected for mobile cache as well.
Marked as RBTC.

🇭🇺Hungary danyg Budapest

Without the updated patch in #20, I still got the following PHP error:
EntityMalformedException: Missing bundle property on entity of type node. in entity_extract_ids() (line 8090 of /app/docroot/includes/common.inc).

Production build 0.71.5 2024