mcdruid → credited jenlampton → .
mcdruid → credited jenlampton → .
quietone → credited jenlampton → .
If we detect the E_WARNING on submission, it needs to stop the form from processing immediately to prevent data loss.
If a form does get processed with more than max_input_vars values, that can sometimes cause things to be deleted - for menus it causes the menu items to be removed, and for permissions it causes those permissions to be un-granted, and removed from the config files (not always database as discussed above).
> I don't think this can be tested unless we're able to add it to .htaccess within a test, otherwise it would depend on the environment.
For tests, we could use a test module with 10,008 checkboxes where the checkboxes are created by a loop.
It looks like this fix was already included over there, so I'm switching this issue back here, but marking as support/documentation so that it will hopefully help the next person: the solution is to update the stripe module, and this problem should be resolved.
Because this patch fixes the stripe_customer module. and that's part of stripe, I'm going to move it to the other queue.
jenlampton → created an issue.
The Backdrop version is available at https://github.com/backdrop-contrib/email_verify.
I think this issue is actually a duplicate of https://www.drupal.org/project/contact_reply_to/issues/2993547 → .
The line indicated has a typo in it, 1contact_name should have been !contact_name
Here's a version of the patch without the fix from https://www.drupal.org/project/contact_reply_to/issues/2993547 → (since I've already applied that one). Switching to RTBC :)
jenlampton → created an issue.
The tip from comment #10 worked for me, but after the upgrade (via the Durpal UI) I still get a failure because update 7301 failed at the rename of the flags table, but succeeded with the rename of the `flag_content` table. Since the whole update needs to be repeated, it's now failing at the rename of the `flag_content` table.
Failed: DatabaseSchemaObjectExistsException: Cannot rename flag_content to flagging: table flagging already exists. in DatabaseSchema_mysql->renameTable() (line 320 of /var/www/html/docroot/includes/database/mysql/schema.inc).
I also made the following changes to `flag_update_7301()`:
function flag_update_7301() {
if (db_table_exists('flag_content')) {
if (!db_table_exists('flagging')) {
db_rename_table('flag_content', 'flagging');
}
else {
db_drop_table('flag_content');
}
}
if (db_table_exists('flags')) {
db_rename_table('flags', 'flag');
}
// A second cache clear appears to be required here...
cache_clear_all();
// ...which in fact isn't enough, as the schema cache appears to need explicit
// clearing to prevent the next updates failing to get the schema for the new
// table names.
drupal_get_schema(NULL, TRUE);
}
jenlampton → created an issue.
The number makes sense if the comments are sequential, but Drupal also allows sites to have replys specifically to a previous comment, breaking the comments out of sequence. In those cases, a number becomes a lot more difficult.
This needed a rebase since it's nearly 10 years old. But still WFM!
I did remove the dependancy on views since this module still works just fine without it, but everything else is here ;)
This almost worked for me, but I had multiple reply-tos. I was able to duplicate similar code used for cc, bcc, and to, that handles multiple addresses, in addition to adding this change.
case 'reply-to':
$mailer->ClearReplyTos();
$rtrecipients = explode(',', $value);
foreach ($rtrecipients as $rtrecipient) {
$replyto_comp = $this->_get_components($rtrecipient);
$mailer->AddReplyTo($replyto_comp['email'], $replyto_comp['name']);
}
break;
The backdrop version is available at https://github.com/backdrop-contrib/one_two_more.
jenlampton → created an issue.
jenlampton → created an issue.
Patch works great for latest release. Thanks!
jenlampton → created an issue.
larowlan → credited jenlampton → .
joseph.olstad → credited jenlampton → .
poker10 → credited jenlampton → .
> Is this in a modal?
no, this is in the body of a page.
> So we need more detailed reproduction steps in this issue, as I could not reproduce the issue.
We discovered that this problem was not caused by the 4.0.3 update, but coincided. Our deploy also accidentally removed the chosen library we were using jjj/chosen and our site fell back to using the obsolete harvested/chosen, which was added by webform. The problem with placeholders was caused by the older library. Replacing the jjj/chosen fixed our issue.
Sorry for the noise, I'm going to close this issue.
jenlampton → created an issue.
jenlampton → created an issue.
I suspect that people were appliying the Drupal 6 patch → to a Drupal 7 theme, so it's not surprising that it didn't work properly.
The Analytic theme does not support drop-down or fly-out menus, but there are a lot of nice modules that will add that functionality. Below are three examples.
- Nice Menus https://www.drupal.org/project/nice_menus →
- Superfish https://www.drupal.org/project/superfish →
- SmartMenus https://www.drupal.org/project/smartmenus →
It appears that the link on Amazon hosting has gone away too, after a while. Closing this as "won't fix".
The menu with the dark background is the "Main menu" and links can usually be added at the path admin/structure/menu/manage/main-menu. No need to get into the code with this request.
You can change the width of the columns with CSS. Here is an example of very narrow sidebars with a wider center column:
.column-1 {
width: 150px;
}
.column-2 {
width: 700px;
}
.column-3 {
width: 150px;
}
Yes, you can do this with CSS:
.column-2 {
width: 730px;
}
.column-3 {
width: 300px;
}
I'm not able to reproduce this problem on a fresh install with the lates 7.1-1.x-dev theme. From the image, I suspect that the content you were trying to place into the left sidebar was too wide for the space available, causing it to "spill" over the edge of the page. I would recommend moving the blocks you have on the right to the left, and the left blocks to the right, to see if it is still happening.
Because this issue is so old I'm assuming you have probably moved on entirely from this issue, so I'm going to close it.
I'm not able to reproduce this on a fresh install with the latest 7.x-1.x version of the theme. There are several modules that add extra padding at the top of the page to make room for other various elements, such as toolbar module and admin_menu module. I suspect that's what you are seeing.
Patch also includes some whitespace cleanup and indentation improvements.
poker10 → credited jenlampton → .
thank you.
(adding code tags)
This looks like a good safety check. marking as RTBC.
I agree, this is a nice improvement. Marking as RTBC.
Patch nolonger applied to 7.100. rerolled.
Updating issue status.
Updating issue status.
Thank you
> #51 suggested linking to WCAG somewhere, but that was never done.
We could link to https://www.w3.org/TR/2012/NOTE-WCAG20-TECHS-20120103/G201.html
The text they include in that example is (opens in new window) so I'm tempted to always use that exact text and not allow for it to be modified. The only use-case for modification would be if someone had already entered the missing warning into the existing link is external text. Making neither configurable would remove that use-case, but I also dislike the idea of removing options that other people think are helpful, especially when they are already out there in use on production sites.
Accessibility isn't optional. Why is there an option for "Add "(New window)" in the title of links that should open in new window."? The answer to that checkbox needs to be identical to the answer to "Open external links in a new window or tab." So we don't need both.
Either the links are opened in new windows (AND they have a warning) or they are not (and there is no warning). There is not a use-case for having links open in new windows without a warning. That's not accessible.
Updating issue description to be more comprehensive.
It looks like people are using https://www.drupal.org/node/3054538 → to discuss the warning, so I'm going to close this issue in favor of that one.
I'm removing the installer module screenshot from the issue description since installer module in Backdrop, and Backdrop upgrades from Drupal 7 have nothing to do with each other. I know some people like to do upgrades that way but since that isn't supported (and can be dangerous) I don't want to encourage it ;)
We do still need the complete list of module machine names for supported upgrade paths (and people can use that list for whatever they want!)
Please also see the GitHub issue for more discussion and other possible solutions:
https://github.com/backdrop-contrib/backdrop_upgrade_status/issues/44
I don't think this information belongs on the "Backdrop Upgrade Status Report" page. It doesn't have anything to do with how ready your site is for Backdrop (and the report page is already very long).
The complete list of modules could go on the Drupal Status Report page, maybe? We could add it there.
We could also add it to the top or bottom of the "Backdrop Upgrade status" page. That page already lists all the contrib modules so it seems like maybe a good fit.
I was also thinking that we could add a page for "Backdrop Upgrade Tools" (or something). A drush or bee command could go there. But neither would really be necessary if we had the complete list of modules, so maybe that's all we need to add.
See related: https://www.drupal.org/project/extlink/issues/3054538#comment-15555115 ✨ A11y: add screen reader text for external links Needs review
jenlampton → created an issue.
> Since the script checks (I assume) these locations anyway, would it be possible to add links to each of the contrib versions it finds into the report to make it super easy to find them?
This is a great idea. I've gone ahead and added the name of the project -- linked to its repository -- to the backdrop upgrade stats report in b1d6c8af7d59b253d48b18b3d93d4d0c57e89bcb.
Leaving this issue open so we can look into the OpenAtrium issues.
I've updated shortcut to indicate the Backdrop contrib version.
I do not know why Search Krumo and Invite were not identified as contrib modules in the screenshot. In my testing they were properly identified and a recommended version was displayed. I suspect it may have been fixed since it was reported.
Added a link that says "See the documentation on supplemental contrib modules"
I'm not seeing this problem in the latest release, it looks like it was fixed with 3e59634d40e6.
my attempts:
> After installing Backdrop Upgrade Status, all Paragraphs edit fields started displaying the Main menu instead of the content of their paragraph.
That's really bizarre! I've tested both and was not able to reproduce this. I might need a little more information. What kind of fields were on your paragraphs? Were they standard text / long text or anything specific? Was it all the fields on a paragraph, or only some of them?
I've got a PR ready for this when the module is ready: https://github.com/backdrop-contrib/backdrop_upgrade_status/pull/43
Great point - I've added the text "No contributed modules detected. Run cron or check manually." (with links to each of those two tasks) as the "empty" value for the list of contributed modules.
As far as I can tell, Date repeat doesn't appear to be deprecated, or at least, I could't find that reference. I checked several versions of the README: https://github.com/backdrop-contrib/date_repeat. Could you drop in a link to where you saw that documented?
Repeating Dates is currently listed as a similar module, but not a replacement. I don't think we should direct people to use a similar module without a supported upgrade path as part of the upgrade, unless Date repeat is definitely deprecated.
Entity reference has been added as a core module :)
https://github.com/backdrop-contrib/backdrop_upgrade_status/commit/80830...
Since merge isn't working on gitlab, I pulled a patch and applied it manually instead.
benjifisher → credited jenlampton → .
Changing to RTBC after the last comment.
That issue appears unrelated to our problems with files. We're now working over here: https://www.drupal.org/project/drupal/issues/3424701 🐛 Cannot delete file when using language negotiation domains Active
This issue summary recommends a fall-back to the edit form, but there are entities that don't have edit forms (files, for example). We have a site with translation that's unable to delete files with this patch. We can also reproduce the problem reliably on other sites if we attempt to delete a file without any destination query argument.
Does anyone know if there is another follow-up issue to address that? I searched but couldn't find one.
Thanks so much!
We are also using this patch on several projects. Marking as RTBC.
jenlampton → created an issue.
longwave → credited jenlampton → .
Could we ask that the documentation be updated for Drupal 10? We're not able to get the module to work at all, and the settings seem very different from the code snippet we are provided by the ShareThis website.
We're currently evaluating possible services to use now that AddThis has died, but ShareThis doesn't seem to be very alive for Drupal either :) Some documentation on how to set it up would be very helpful.
xjm → credited jenlampton → .
xjm → credited jenlampton → .
lostcarpark → credited jenlampton → .
jenlampton → created an issue.
The menu item is still where it was under Structure, but the URL has changed to match admin/content. I think the update hook might have been overlooked for existing sites?