I’m not sure that my issue is quite the same as that reported here, but I too am finding that the DESCRIPTION property is not being formatted as expected in the .ics feed.
I’ve attached an example .ics file (saved as .txt for uploading as: calendar-test-d10.txt → ) created in Drupal 10 (10.3.10) with Date iCal 4.0.10. If you open this you will see that the DESCRIPTION property contains HTML paragraph tags where I was expecting to see /n as the paragraph separator. Also, I would have expected the HTML <strong> tag to have been removed.
When entered into the calendar on my Android phone/tablet, all is well, but when loaded into the Microsoft Outlook calendar on my desktop PC, the HTML tags are not recognised as such and appear, uninterpreted (see screen shot of Outlook entry attached: calendar-test-d10_in_Outlook.png → ).
My setup in Drupal 10, as far as I can see, mimics that which I have been using successfully in Drupal 7 for years without issue. The same calendar entry generated there (using Date iCal 7.x-3.12) has all HTML tags removed and the expected /n to separate paragraphs (see calendar-test-d7.txt → attached). This renders correctly in both Outlook and my Android devices.
In the above cases I have a single content field configured as the DESCRIPTION property. I have found; however, that if the iCal view mode display for my content type is set to display that same, single field and I include this as a "Rendered entity" field in my iCal feed view and set this as the DESCRIPTION property then, in addition to the DESCRIPTION property in the .ics feed, I see also the X-ALT-DESC property (see calendar-test-render-d10.txt → ). When I load that feed it renders AOK in both Outlook calendar and in my Android devices (Outlook screenshot: calendar-test-render-d10_Outlook.png → ).
That’s great, but I want to be able to create some calendar feeds with the DESCRIPTION property set to be the rendered entity and others with an individual content field configured directly as the DESCRIPTION property – and with the X-ALT-DESC property present only when utilising the rendered entity method, the directly configured individual content field method isn't working for me.
Am I failing to configure something correctly or is there really an issue when an individual content field is configured directly as the DESCRIPTION property, rather than a rendered entity being configured as the DESCRIPTION ?
I've just added a comment to 🐛 Error: Call to a member function Output() on null in Drupal\views_pdf\Plugin\views\display\PDF::buildResponse() (line 141 of modules/contrib/views_pdf/src/Plugin/views/display/PDF.php). Active noting that with caching turned on, PDF pages on a Drupal 7 site that I have will only load once.
By default, caching had been turned off on that site, and there had been no issues with pages loading more than once. I tried turning caching on, just to see what would happen. The results then (with Views PDF 7.x-3.1) are similar to what I am seeing now with Views PDF 3.0.0-alpha10.
I've suggested that we need a view from a maintainer as to how to proceed as it would be good to move Views PDF 3.x beyond an alpha release.
I suggested previously that "it would be nice to have a "proper" fix" for this issue; however, a test on a Drupal 7 site I have suggests that Views PDF may never have worked with caching turned on.
The PDF display in my Drupal 7 view has caching turned off by default and has been working happliy for years. I tried turning caching on, and found that only once would the PDF page load successfully - the second attempt does load an A4 page, but it's blank. There is no error message to indicate why this might be.
Tested with Drupal core 7.103, Views PDF 7.x-3.1, PHP 8.1
Should we accept that Views PDF (3.x-dev) requires PDF displays to have caching turned off? Or is there a bug that should really be fixed? What does the maintainer have to say on this?
If we are to accept that caching needs to be turned off, then the documentation needs to state this.
With version 1.0.0 of Statistics module, on Drupal 10.3.10 and PHP 8.1.30, I've run the following tests - first without and then with the changes in MR !7 applied:
Clear caches;
Load a page with number of views showing;
Note number of views;
Load a different page;
Reload the first page;
Note number of views.
WITHOUT the MR !7 changes in place, on reloading the first page, the displayed number of views is unchanged from when the page was first loaded. Displayed number of views only increases after clearing caches.
WITH the MR !7 changes in place, on reloading the first page, the displayed number of views is incremented by 1 from when the page was first loaded. Further reloads result in further increments of the displayed number of views - no need to clear caches.
In other words, for me, the changes in MR !7 fix the failure to update issue.
I've manually applied the change in MR !9 to my site running:
Drupal 10.3.10
PHP 8.1.30
Views PDF 3.0.0-alpha10
The error reported above is no longer seen, so this issue seems to be fixed, thank you.
To test my conjecture that this issue might be the root cause of issue 🐛 Error: Call to a member function Output() on null in Drupal\views_pdf\Plugin\views\display\PDF::buildResponse() (line 141 of modules/contrib/views_pdf/src/Plugin/views/display/PDF.php). Active I set the caching of the PDF View back to "Tag based" - I had previously changed it to "None", the known work around for 3355295. I find that:
First load of the PDF works fine, with no reporting of the error giving rise to this issue (3426719).
Second attempt to load the PDF causes a blank page to open. Prior to introducung the MR !9 change I was seeing a "The website encountered an unexpected error. Try again later." on-screen message. Also, the warnings and error previously reported in the log are no longer present with the MR !9 changes in place. As before, clearing the caches, allows the PDF to load on a second attempt.
It is now clear to me that these two issues are related and I am, therefore, flagging them as such. And whilst there is a work around for 3355295 it would be nice to identify a fix that obviated the need for it - but with no on-screen message and nothing in the log, there's maybe not much to go on.
stevewilson → created an issue.
I too am seeing this (in the 3.0.0-alpha10 version). I'm also seeing issue 🐛 Error: Call to a member function Output() on null in Drupal\views_pdf\Plugin\views\display\PDF::buildResponse() (line 141 of modules/contrib/views_pdf/src/Plugin/views/display/PDF.php). Active and I wonder whether this issue (3426719) is the root cause of 3355295? Why do I wonder this? Because clearing the caches provides relief for 3355295, and the error message for this issue includes reference to Drupal\Core\Cache\CacheableResponse. May be a Red Herring, but I thought it worth mentioning.
I too am seeing this, but I'm also seeing 🐛 Return value must be of type Symfony\Component\HttpFoundation\StreamedResponse Active on the first (successful) generation of the PDF. The error message in 3426719 references Drupal\Core\Cache\CacheableResponse, so I was wondering whether that issue might be corrupting the cache in some way and explain why clearing the caches following the first PDF generation allows the PDF to be generated successfully a seconf time? Will fixing 3426719 fix this (3355295) issue too?
Further information:
When the second attempt to generate the PDF fails, I also see 3 warnings:
Warning: Undefined array key "view_build" in Drupal\views_pdf\Plugin\views\display\PDF::buildResponse() (line 139 of /home/techsoco/d10-dev-2.techsoc.org.uk/public_html/modules/contrib/views_pdf/src/Plugin/views/display/PDF.php)
Warning: Trying to access array offset on value of type null in Drupal\views_pdf\Plugin\views\display\PDF::buildResponse() (line 139 of /home/techsoco/d10-dev-2.techsoc.org.uk/public_html/modules/contrib/views_pdf/src/Plugin/views/display/PDF.php)
Warning: Attempt to read property "pdf" on null in Drupal\views_pdf\Plugin\views\display\PDF::buildResponse() (line 141 of /home/techsoco/d10-dev-2.techsoc.org.uk/public_html/modules/contrib/views_pdf/src/Plugin/views/display/PDF.php)
As with other respondents, I find that the inability to load a PDF a second time is elliminated by disabling caching on the PDF View, but it would be nice to have a "proper" fix. Note also, that with caching disabled, issue 3426719 is still present.
I will add a comment to 3426719 as well, questioning whether there is a link to this issue.
And even before that it was reported as 🐛 Fields marked "exclude from display" do not produce tokens for use in subsequent fields Fixed - and is flagged as fixed! I shall check that out and apologise for wasting your time, but I started scrolling down the list and came to the others first.
I've just noticed that this had previously been reported as 🐛 Fields hidden from display don't show up later when required Active . So this should probably be flagged as a duplicate.
I too am seeing this. It occurs wherever a hidden field is included as a token within the display of another field (e.g. in "Rewrite results" and "No results behaviour") as well as in "Global: custom text" - broadening issue title accordingly. And as this worked perfectly in the Drupal 7 version I regard it as a bug rather than a feature request.
stevewilson → created an issue.
I'm using FPDI 1.6.2 on Drupal 7 with Views PDF 7.x-3.1. I was under the impression that this is the latest version of FPDI compatible with Views PDF for Dupal 7.
I've added a further deprecation to the Issue summary - as seen with PHP 8.2.
stevewilson → created an issue.
There has been no progress on issue 📌 Remove 'fast_404.excluded_paths' from system.performance.yml Needs work since I set this issue as Postponed. The suggestion in the Responsive Favicons README.md file to "Alter the config setting `system.performance.fast_404.exclude_paths` in your `settings.php` file:" remains inappropriate in Drupal 10 as that setting within settings.php no longer exists. The Responsive Favicons README.md file therefore needs updating in the next release of the module. I'm afraid I don't understand enough to know what the update should be.
Setting this back to Active.
I too was seeing this. The patch at #2 fixed it, so +1 for RTBC.
This fixes the issue for me. Setting to RTBC.
I should perhaps add that I was also seeing PHP8.1 deprecations reported by TCPDF - I was using version 6.3.2. I've since updated to the latest version (6.6.5) and everything seems to be fine now.
Thank you @ankithashetty. I've manually incorporated your MR !5 changes into my test site and I'm no longer seeing the deprecation reported at comment #5 🐛 PHP8 deprecated function warnings Needs review . Given that the patch at #2 🐛 PHP8 deprecated function warnings Needs review was previously RTBCed for the deprecations reported originally, it seems safe now to set this issue back to RTBC - done.
@killua99 - I've added this new deprecation to the Issue summary - I hope that's what you wanted.
If you need any further information please let me know.
Changed Status to "Needs work" as the existing patch doesn't cover this latest deprecation and I don't feel confident to provide a fix for it.
I'm seeing a further PHP8.1 deprecation in views_pdf_template.php:
Deprecated function: Automatic conversion of false to array is deprecated in PdfTemplate->addPage() (line 988 of /var/www/html/d7-dev.localhost/sites/all/modules/views_pdf/views_pdf_template.php).
Should we address that one here also, or shall I create a separate issue?
SteveWilson → created an issue.
I too was seeing this issue. The patch referenced at #5 works for me so marking as RTBC.
Thanks @joseph.olstad, all working well now.
This seems only to incorporate only the first change, not that at line 4872?
iCalcreator was forked to https://github.com/lkmorlan/iCalcreator/releases/tag/v2.20.4 by Liam Morland → to address issue #2707373: PHP 7 support with iCalcreator class → . Do we need Liam to update that fork?
It would be good to have a fresh release of the iCalcreator library fork but I am nevertheless encouraged that my proposed fix has belatedly garnered some support.
I've manually applied the changes at #29 which seem to fix the issue for me.
I'm keen to see the fix for this issue committed, so I'd be really appreciative if somebody could sort out the issues with the failed tests that seem to be the stumbling block. I'd be happy to help, but as I'm not a programmer I'm not sure how I could actually contribute.
I think that the introduction of Drupal 7.98 is a red herring. I installed 7.98 and removed the Imunify360 exception, and yes, module updates then installed correctly. But I wanted to test whether it was the HTTP to HTTPS change in D7.98 that fixed it. So I set:
$conf['update_fetch_url'] = 'http://updates.drupal.org/release-history';
in settings.php and retried a module update - it worked perfectly.
I poked around looking at other changes in D7.98 but got nowhere. So I decided to revert a site to a pre D7.98 state - just to confirm that the issue is still present there. It isn't - having reverted to a D7.96 site and database backup I tried a module update and once again it worked perfectly.
I am forced, therefore, to conclude that a faulty, corrupt or inappropriate rule in Imunify360 was causing this issue and that it has now been fixed.
Whether I'm right or wrong, I'm happy for this issue to be closed.
I don't know whether it helps, but attached is the full Imunify360 report, for the action it performed, for one of my failed Drupal module updates (it's a sequence of screenshots I'm afraid - I couldn't see how to export the report).
The Imunify360 change log indicates that changes are introduced very frequently.
Thanks @bearstar, this also works for me. For the sake of completeness, and for Drupal core maintainers, I've included a screenshot of the imunify360 error message.
If I gave the impression that I'd experienced this fault on different servers I apologise - I am hosted only on Krystal. We know that two of us experiencing this issue are hosted on Krystal, but there are others who have not declared their hosting service. We cannot, therefore, be certain that the issue is unique to Krystal hosting.
Thanks for doing that @Robar. Please do report here the outcome of your investigation with Krystal.
I too am hosted on Krystal.uk. Is this the case for other users experiencing this issue?
I'm not using a private file system, it's a standard build profile.
sites/all/modules permissions are 755, as are sites/default/tmp.
Module files are definitely downloaded to tmp and extracted there. tar.gz file is in update-cache-xxxxxxxx, extracted folders/files are in update-extraction-xxxxxxxx.
I too conclude that this issue is not caused by a recent Drupal core update - when I revert to 7.94, the module update that previously worked, no longer does.
I'm running on in a shared hosting environment. Could this issue be caused by a change my hosting supplier has made?
Attached is a screenshot of what I see when attempting to update the Content Access module on my test site.
Contrary to what the issue summary states, the compressed (in my case) Content Access module file is downloaded to the tmp directory and is extracted there. The previous version of the module is deleted from the modules folder, a Content Access folder can be seen there, but all it contains is an empty README.MD file.
Thanks ankondrat4, I truncated cache_update table and attempted another module update (using my current configuration of Core 7.96 and PHP 7.4) - the error persists.
Sorry @poker10, as a user, not a developer, I need to question how to make those changes.
update_max_fetch_attempts I see is a constant defined in update.module - do I simply edit the value in this file and save it? Change 2 to 4 perhaps.
And I can see the cache_update table using phpMyAdmin, but what exactly do you mean by "truncate" this.
Or maybe someone more experienced should move this forward?
I too am seeing this issue, but I don't think it's caused by a cahnge to Drupal core.
The last successful module update I performed was on 27 February 2023, running Drupal core 7.94 and PHP 7.4. I made a site and database backup immediately before performing the module update. I've restored those backups and attempted to repeat the module update - it now fails.
My PHP extensions were previously set as per those in #17. I have subsequently changed them, but on reverting to those previous settings I still get this module update issue.
I don't know where to look next.
The source of the issue for me appears to be line 205 in mimemail.module. My knowledge of PHP and Dupal module constructs is minimal but the following change removed the deprecation I was seeing:
- 205 $message['params']['plaintext'] = token_replace($params['plaintext'], $context, $options);
+ 205 $message['params']['plaintext'] = !empty($params['plaintext']) ? token_replace($params['plaintext'], $context, $options) : ($params['plaintext']);
I'm not going to be so bold as to suggest that this is an appropriate fix for the issue, but it does seem to confirm this line as it's source.
It's also clear that line 204, which performs the same token replacement on the Body field will, if no Body text is entered, give rise to the same deprecation as seen with an empty Plain text body field. (In my test Rule above, I cleared the Body field and entered the text instead in the Plain text body field to prove this.) A similar change to that made in line 205 once again removed the deprecation.
I'm presuming that token replacement on the To and Subject fields (lines 202 and 203 respectively) will not not give rise to the deprecation as these fields are designated on the form as Required fields and hence will never be empty?
But what about lines 51 and 57 in mimemail_action.module? Are they a concern?
A limited contribution I'm afraid, but hopefully it might help move things along.
And corrected typo in title.
I've added 📌 Remove 'fast_404.excluded_paths' from system.performance.yml Needs work as a related issue as it would appear that the fate of 'fast_404.excluded_paths' is not yet settled. We need agreement there before the documentation for this project can be updated reliably. I've therefore set the status of this issue to Postponed.
I've created a very simple Rule Component that exhibits the reported characteristic. I uploaded it as a text file but can't see how to reference it (sorry - more learning required) but, as it's small, I'm pasting it here:
{ "rules_html_e_mail_test" : {
"LABEL" : "HTML e-mail test",
"PLUGIN" : "action set",
"OWNER" : "rules",
"REQUIRES" : [ "rules", "mimemail" ],
"ACTION SET" : [
{ "mimemail" : {
"USING" : {
"key" : "html_email_test",
"to" : "[site:mail]",
"subject" : "Send HTML e-mail test",
"body" : "Testing for preg_match_all() deprecation.",
"language" : [ "" ]
},
"PROVIDE" : { "send_status" : { "send_status" : "Send status" } }
}
}
]
}
}
As you can see, it's an Action set with a single "Send HTML e-mail" Action, to send an e-mail to the administrative e-mail address for the site.
When I execute the Component from the Administration » Configuration » Workflow » Rules » Components page with PHP 8.1 set, I get the reported deprecation in the log. With PHP 7.4 set, there is no deprecation. If, via the user interface form, I add some text to the Plain text body field, the 8.1 deprecation is no longer reported.
SteveWilson → created an issue.
SteveWilson → created an issue.