🇺🇸United States @jimmb

jimmb → created an issue.

Just one last note that I'm okay if these things are not resolved. Considering the screenshot in my last comment, if that's how this block is going to display on this website -- given the amount of pages and length of their titles -- then it's basically unusable anyway.

The only thing here that *is* still needed is the Book Traversal Links' functionality. I will open a new issue for this specifically.

I hate to reopen this, but I just tested with Book 'Book 2.0.0-alpha-5'. There are definite improvements, but a couple issues are still present.

Note: I have switched my theme to Olivero on a staging site for these comments. I'm assuming Olivero is a good simple theme to test with (let me know if I should use something else).

Results of latest testing, after placing the 'Book navigation' block into the 'Sidebar' block region:

a. The 'Book navigation' block is showing up for anonymous users as expected. --> This is still the case = PASS

b. If I add another block to that same region, then all the blocks disappear for anonymous users. --> This doesn't happen now - the 2nd block just appears along with the Book navigation block = PASS

c. The 'Book navigation' block is NOT showing up for logged-in users (when only 1 block is in that region) --> This is showing up now as expected = PASS

d. Also, for anonymous users, there is a link at the bottom of any book node for 'Add sibling page'. I assume this should not be seen, since anonymous users have no permissions to add content? --> This is still showing up unnecessarily = FAIL

e. Also, when logged in, the 'Book trraversial links' section is not showing up anymore. I'm only seeing "Add child page", "Add sibling page" and "Printer-friendly version" links. --> This is still the case = FAIL

Lastly, I'll just make a note that the indentation of each book page list item quickly takes up all the space in the block, creating numerous text breaks and making the text pretty unreadable. I've attached a screenshot of this for reference. I'm guessing this indentation can be solved with CSS, but still overall there seems to be an opportunity at the design level to make this work better.

Thanks for the clarification on MR - now I know what that means!

So, being that I'm a low-code site builder, and that my book project is being built on a staging site, I'll probably wait until your fixes are merged into the next tagged release.

But until then, it's great to know that most likely these issues have been addressed now.

Hello - I'm still seeing all the same problems and am not seeing a new release to check with .... So how can this be marked as fixed?

Also, apologies, but I don't know what "MR" stands for. So I'm not sure what to do with that question....

But overall, there were multiple bugs happening for me and so I'm not sure how this ticket can be closed yet. Especially when I'm not seeing any change on my side.

I have a couple more updates now, after updating to Book module vsn. 2.0.0-alpha4

1. I switched the default theme to Olivero, and placed only the 'Book navigation' block into a desired block region. Results:

a. The 'Book navigation' block is showing up for anonymous users as expected.

b. If I add another block to that same region, then all the blocks disappear for anonymous users.

c. The 'Book navigation' block is NOT showing up for logged-in users (when only 1 block is in that region).

d. Also, for anonymous users, there is a link at the bottom of any book node for 'Add sibling page'. I assume this should not be seen, since anonymous users have no permissions to add content?

e. Also, when logged in, the 'Book trraversial links' section is not showing up anymore. I'm only seeing "Add child page", "Add sibling page" and "Printer-friendly version" links.

2. I switched the default theme back to DXPR (what this website is using normally). Results:

a. The 'Book navigation' block is still NOT showing up for anonymous users.

b. The 'Book navigation' block is still only appearing for logged-in users if another block is placed in that same region. I've tried with 'Search' and 'Who's online', and having either of those in the same block region makes 'Book navigation' appear.

c. The 'Book traversial links' is also not appearing for anonymous users anymore. Maybe that has gone away with the newer alpha versions of this module? I hope not, though, since that is a very helpful feature that was core to the old Book module.

End of report for now - hopefully this is helpful and that these things can be fixed.

In my case, I took the advice to "select Node from URL from the context filter", and that helped a little ... Here are my current settings:

- At /admin/structure/block, I have 2 blocks in the desired block region: "Who's online" and "Book navigation". For both of these, under 'Visibility' I've set them to only appear on book nodes

- At /admin/structure/block/manage/dxpr_theme_booknavigation?destination=/admin/structure/block, I have the following settings:

-- Under 'Book navigation block display', I've selected: Show block only on book pages
-- Under 'Node', I've selected: Node from URL
-- Under Visibility > Book, I've checked the boxes for both of the books I've created
-- For everything else (Response Code, Pages, Response status, Roles, Content type, Vocabulary), I've left things as is. Note: this means for 'Content type', I've checked none of the boxes including "Book page" (assuming the setting 'Show block only on book pages' should take care of it).

And with these settings, this is what I've getting:

- When logged in, the "Book navigation" block is showing up now as expected.
- When viewing the same page as an anonymous user (i.e. logged out), the 'Book navigation' block is not showing up. It should be appearing, though, since I'm not restricting the display of this block by role.

- When the 'Who's online' block is also active in that block region, then the 'Book navigation' block appears as expected
- If i remove the 'Who's online' block from that block region (so only the 'Book navigation' block is there), then the 'Book navigation' block disappears. This should be appearing, though, regardless of whether another block is there as well.

So overall, it does seem that selecting "Node from URL" does help to make this block appear. But there are still some other issues that need addressing. I've included my other settings above in case that helps to narrow down some of this.

Final note: these notes were made after upgrading the 'Book' module to 2.0.0-alpha3

jimmb → created an issue.

jimmb → created an issue.

jimmb → created an issue.

Hello - I believe there have been 2 incremental updates to this module since I posted this issue. And after applying the most recent update a couple days ago, I'm still seeing the faint bullets.

I'm also not sure why the issue status is still at 'Needs Review', when it sounded like there was a clear fix?

So it makes me wonder - are you expecting me to apply the patch and review this? Personally, I'm a low-code/no-code site builder and am hesitant to apply patches or do things like that unless it's *absolutely* necessary. I was assuming you would have a way of reviewing this on your side as well...

So I'm just wondering if I need to do something further, or if I just need to keep being patient (very patient) for this tomake it into an upcoming release.

Thanks very much for the reply. And in light of this, then it looks like there may be 2 bugs ...

For #1, it's good to at least know the likely cause of this. It's obviously not essential, but would be nice someday if this just showed the e-mail address like the default Drupal setup.

For #2, I double checked and 'URL to absolute' is there. I've attached a screenshot from /admin/config/system/mailer, which shows that it's active. As such, I'm guessing that is a bug as well.

Any ideas to troubleshoot this would be much appreciated. And naturally if you can fix either or both of these bugs, that would be fantastic!

jimmb → created an issue.

Thanks very much for the helpful reply and screenshot! So far, my CSP setup is completely using the default settings, and this is what I did:

1. Installed https://www.drupal.org/project/reporting → (with Composer) and enabled the module

2. Went to /admin/config/system/reporting and viewed the 3 Reporting Endpoints that exist by default with this module, and made no changes

3. Went to /admin/config/system/csp and did the following:

- Under Policies > Report Only (which is enabled), I left everything as is but at the bottom in the 'Reporting' section I changed the 'Handler' to "Reporting Endpoint" and then for 'Endpoint' selected: Content Security Policy - Report Only (as per your screenshot)

- Under Policies > Enforced (which is enabled), I left everything as is but at the bottom in the 'Reporting' section I changed the 'Handler' to "Reporting Endpoint" and then for 'Endpoint' selected: Content Security Policy - Enforced

And now back on the Status Report page, I'm seeing that warning is gone. So hopefully I've done everything that was mentioned (or implied) in your comment, and I'll assume everything is correct now.

I must confess I'm not totally understanding your last paragraph, but in general I'm thinking this new Drupal 10 site -- which has otherwise been built assuming users are on current browsers -- will have users using ~ the latest versions of Chrome, Firefox, Safari and Edge. And so hopefully this should be fine - unless a warning pops up in the future that tells me otherwise.

Thanks so much for the reply! I'd considered doing what you suggested, but thought it would also remove the homepage on the main domain from being indexed....

But I just went into 'Edit' mode for /homepage, and selected "Do not index this Landing Page entity in sitemap". I then went to /admin/config/search/simplesitemap and clicked "Rebuild queue & generate".

And afterward, viewing my domain.com/sitemap.xml, I am seeing the main domain (i.e. the de facto homepage) as being indexed but not the redundant /homepage page. So this looks perfect now!

Thanks again for the help, and I will close this issue.

jimmb → created an issue.

I'm also having this problem, having built a Drupal1 10 site with Layout Builder and consequently having a node for the homepage (/homepage) that's also loading at the main domain URL.

As such, in the XML sitemap, I'm seeing the same page twice: domain.com and domain.com/homepage

My question is about this from comment #2 above:

you should ... go to admin/config/search/simplesitemap/custom and exlude the path /.

This would be a perfectly fine solution in the UI, but I'm not seeing how to do that. At /admin/config/search/simplesitemap/custom, I'm just seeing 'Add custom internal drupal paths to specific sitemaps.' and the 'Default' field below that (neither of which seem to apply here). And under that is 'Include images', which also isn't applicable.

So, where is this field where I can plug in "/homepage" as a relative path and have it excluded from the XML sitemap generation?

Thanks so much for the reply, and that makes sense! So now at /admin/config/symfony-mailer-lite/message-settings, I checked the box for "Always use the default content type". And now, after doing some more tests, those 2 notifications e-mails are sending as HTML.

I appreciate also the note on the text formatting. Really, everything looks good to me by default *except* that the line breaks are missing. This is pushing sections of text together when there should be some spacing. For example, the plain text formatting in the e-mail notification looks like this:

Paul Rollins (not verified) (name@mail.com) sent a message using the
contact form at https://staging.domain.com/contact.

Message
Testing the e-mail setup again, after thinking I'd gotten it correct ...

But now, that message is formatted like this:

Paul Rollins (not verified) (name@mail.com) sent a message using the contact form at https://staging.domain.com/contact.
Message
Testing the e-mail setup again, after thinking I'd gotten it correct ...

As you can see, it'd look a lot better if there was a space (or line break) between the first sentence and the "Message" line of text.

So I'd like to do what you mentioned about adjusting that format if I'm unhappy with the results of the conversion. But I'm not sure where I would do this - is it in the UI (hopefully) or somewhere else? Also, if I just want to have the HTML follow the line breaks as they appear in the plain text, it'd be great to know what change(s) you'd recommend making to accomplish this.

The Mail System maintainers helpfully replied, and made it clear that any such issues would be with this module. After that, I happened to (finally) stumble across and realize there is an additional GUI admin section for this module that I'd missed before...

So here's where things are at now:

1. At /admin/config/system/symfony-mailer-lite/transport, I added the 'Sendmail' Transport type and made it the default. I otherwise left all settings as is.

2. At /admin/config/symfony-mailer-lite/message-settings, I changed the 'Default Content Type' to "HTML". I left 'Always use the default content type' as unchecked. For 'Text format', I left that as "Plain text". For 'Plain Text Version', I left the option there as checked. And for 'Character Set', I left that as "UTF-8".

3. At /admin/config/system/symfony-mailer-lite/test, I then sent a test e-mail. It was received at an Outlook account, and says the module has been successfully configured. The text here also spans across the full width of the computer screen, so that looks great and I assume indicates it's sending as HTML

4. Next I went to the website's contact form and submitted it, but unfortunately I'm still seeing the same plain text line breaks on both e-mails. So I flushed all caches, and tried again. But to my dismay, I'm still seeing the e-mails as plain text. For what it's worth, the auto-reply e-mail is being sent to an account on mail.com, and the e-mail notification message is sent to a Gmail account.

Note also that I have set up SPF and DKIM for the website, and have already verified that these are in place with the contact form's e-mails.

I suppose the only other note is how things are set up currently on the Mail System page:

Default Mail System: Formatter and Sender are set to: Default PHP Mailer
Theme to render the emails: Current

Under 'Module-specific configuration', the following are set:
Module=Drupal Symfony Mailer Lite, Key=All, Formatter=Drupal Symfony Mailer Lite, Sender=Drupal Symfony Mailer Lite
Module=Contact, Key=All, Formatter=Drupal Symfony Mailer Lite, Sender=Drupal Symfony Mailer Lite

So it seems to me this is all set up correctly (assuming I want other system e-mails like password resets to remain handled with the default Drupal mail system as plain text, and the Contact form to use Drupal Symfony Mailer Lite as HTML).

I really don't know what else to try, if something is still set up incorrectly, or if there is a legitimate bug or issue with this module.

I will look forward to, and indeed expect, a reply from someone for this support request.

Thanks for the info, and I understand now. It would be nice if this was part of your README file or project description, so it's more clear what this module does and doesn't do. In this case, it would have saved me various stages of testing and ultimately feeling like I had to post this support request. Anyway, thanks again for the help and I will proceed via the original issue.

Update: I've now removed this module and run some tests with only the Mail System module. And the e-mails still appear to be sent as plain text (i.e. the line breaks are still happening as before).

So perhaps this is more of a problem with the Mail System module. As such, I've also created an issue on their project page, and added it here as a related issue.

jimmb → created an issue.

As a 2nd test, I changed the 'Theme to render the emails' to "Claro" (which is the administration theme). After saving the changes and clearing all caches, I submitted another contact form entry.

Again, it's displaying only as plain text and breaking the lines as before.

jimmb → created an issue.

Thanks for the reply, ravi - much appreciated. So it sounds like you're handling the QA testing side, and I'm not sure who is doing the community reviewing and testing (but I assume that is covered as well) ...

So fro now, I'll be patient and wait for the next module update. I'm just about ready otherwise to make this website live, so you can understand why I'm looking forward to this being ready as well!

Well, I found that putting the "composer.json" stability at "dev" was the only way to get these libraries to install. It would be nice to include that in the documentation. And since it's apparently undesirable to have a project with the stability at "dev", it'd be even better to include an example command that installs just those libraries at "dev" while leaving "stable" in place for everything else. That would really be good to know how to do from your README.

Also, I found that running composer require wikimedia/composer-merge-plugin only installs 3 of the 4 libraries that are needed. For me at least, jQuery HoverIntent was not installed. So the documentation should also include this info. and provide a recommended way to install that.

And since then it seems like you need to do some manual installation anyway, maybe it's better to just install everything manually using the drush commands in the README? That way, presumably, the default stability could remain at "stable.

So again, the documentation should really be updated to help the average low-code user still be able to use this module without having to spend days trying to figure all this stuff out (and then still not really know what to do).

Thanks @ravi, your solution looks like exactly what is needed!

I see the status now is "needs review".

Let me know if there is something you'd like me to do to help review your fix. Otherwise, I look forward to seeing a new module version release that includes the fix.

Also, from the Composer info, I tried running composer require wikimedia/composer-merge-plugin:*. That output this:

Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - Root composer.json requires douglascrockford/json2 *, found douglascrockford/json2[dev-master] but it does not match your minimum-stability.
  Problem 2
    - Root composer.json requires malsup/jquery.cycle *, found malsup/jquery.cycle[3.0.3-a] but it does not match your minimum-stability.
  Problem 3
    - Root composer.json requires tobia/jquery.pause *, found tobia/jquery.pause[dev-master] but it does not match your minimum-stability.

I can't be the first person having this problem, so I'm sure a solution exists and we just need to be made aware of it.

jimmb → created an issue.

jimmb → created an issue.

Sorry to have to resurrect this issue, but this is still happening. Apparently that other change → didn't fix the issue after all.

I'm using version 2.0.4 of this module on a Drupal 10.2.6 website. The PHP Version is 8.3.6 if that matters.

What I'm seeing is exactly like the other posts in this thread. For me, and other users who I've heard from, usually the first time the website is loaded, the slideshow does not load at all.

This is a site where the slideshow provided within a block, and is on the homepage only. Anyway, you either have to refresh the homepage, or navigate around the site to some other pages and then return to the homepage to see the slideshow.

It would definitely be great to have this working reliably, since otherwise it's a very nice slideshow that does everything that I need.

Well, it is confusing since I've read on The Drop Times that this module requires the jQuery Cycle plugin...

However, after enabling and configuring the module, and adding a few images, I see that the slideshow cycling of images is working.

I'm not sure *how* it's working, but I will close this issue.

jimmb → created an issue.

Also, when looking at the 'error log' in the document root, there is this:

Uncaught PHP Exception Drupal\Component\Plugin\Exception\PluginNotFoundException: "The "menu_position_rule" entity type does not exist." at ... /docroot/core/lib/Drupal/Core/Entity/EntityTypeManager.php line 139

jimmb → created an issue.

jimmb → created an issue.