indeed, combining generations of BS would be a large amount of support from one module.
https://www.drupal.org/project/bootstrap_five_layouts →
. I'm forking for this reason. cheers.
update: items 1 & 2 are currently wip on main dev. may wait till after first release for pt3.
+1 more.
patch allows by view to work as expected.
@megachriz
i'm not actually clear on the difference as kopfduenger outlines in 127.
To report, at least on my own testing with this:
-> i'm using a Custom Parser in my client project as they have a feed with several custom field names in a feed. in short: patch works as designed. It did successfully take the image page and save out the media item. +1
re: 127. have opened branch '2928904-127-feeds-combined-media-fix' with this patch for wider testing.
Thanks! local test given my same steps now have no error!
thanks i-trokhanenko -- a good reminder in general to check around. I'll have to re-check that project for this point for my own situation (can not confirm at the time....)
#7 is indicating steps to reproduce. #8 (video is broken) simply is not able to assist.. lets return to needs work, as there is no patch.
i have tried this patch. it didn't not resolve for me.
seems that re-inistalling has re-addressed this glitch (between both plugins?). not clear what had happened...
works as expected. please promote a release!
2 cents:
in situations where i've seen these types of ban tools used...my general opinion is that trying to block within a PHP runtime (drupal) is not successful in heavy load situations as the server is already in crisis. trying to get to an admin path, or trigger drush commands -- tends to fail at those points too. These tools are not the best way to safeguard a running app. IMO.
adding 'blockible path' to htaccess (items like /wp-admin) is should be done if that is to scope concern of that site owner...
Please review the issues you are concerned with from those issues directly. thanks!
moving to 3.x line as this is one of the goals in to make the Bid form more available.
2.2.2 release. have recently fixed a 'logger' bug in the cron task -- this was blocking status changes.
moving to needs review even though is released.
bid have a 'relist' id, are you sure the Bid you deleted belongs to the current active relist. this could be one side of the UI.
the view for the list seen on Auction Nodes (public) would be found on View admin/structure/views/view/bids_relist_group -- this is set with a cache tag. you may need to adjust that setting.
have moved to hook_install/uninstall of order item and some related config cleanup on 2.2.2 release
won't fix. this is glitch of 'Upgrade Status' and how it processes versions. As COMPOSER is actually the perfered way to 'load all the things' this is the only concern (and works as expected).
see previous related (closed) ticket,
3.0.x is still set as dev line only release for now final Commerce Core 3.
cheers. have released 2.2
I've actually determined that because Commerce Core is cutting off at 10.3 is causing the build problem this way. I'll need to shift it over on the 3.x line anyway.. I'll set up a 2.2.0 release for THIS ticket.
https://www.drupal.org/about/core/policies/core-release-cycles/release-p... →
Honestly, as this project is not funded by Users in any way I am not looking to maintain what CORE is doing with maintaining such ''long term" majors (2 Drupals at once). Core has too much consistency. in NOT being a true base. this is why I already have several releases version. as that proof.
note: this bug sounds like something that was known with order items.. (if memory servers me).
moving to dev3 line.
Assuming you have your composer.json setup to use Patch, you can apply the "plain diff" of this patch from the dev line of the projects repo
noted. thanks.
Seems like it would be a good time to include Drupal 11 in the modules .info.yml. I'm not sure if tests are running here..
joevagyok → credited skaught → .
duplicate of #3420902
certainly, lots of open tickets around this in core..
Drupal issues search | "text=not+compatible&component=update.module" →
this is how this module is currently set for release status:
it seems like core isn't figuring out that what's recommended isn't geared per core release.
As per #50 and #48. I'll move to RTBC logo is aligned with the rest of items below, matching overall design mocks.
#48 notes. " But there should be some space between logo and slider." I would agree the width of the entire item might ought to be wider but that scope that might pushing this ticket IMO. Also, as we know various browsers use different widths.
to be clear, I was staffed by Optasy for work on the estore project.
thanks for confirming your hosting platform. Indeed, this module IS NOT STABLE!!
this module is not maintained!
umm.. I see you have scrollbars being displayed. Do you have your setup to always show them?
preview with flex-shrink attached, shows both of our toggles between breakpoints.
local demo image was just 71*83 pixel grab (then autosized as expected to 34x40).
have reviewed patch. yes oversight in original name spacing for file usage.
will also probably need an update hook to check if any update any existing entries to be updated to 'file' (as $new_logo_managed->getEntityTypeId() will equal 'file').
also was using drupal 11 (a new site, not an updated project). I had come across several other bug/error notices. this is the only one that was fatal/wsod.
the_g_bomb → credited skaught → .
on 3.x dev I am now converting to a custom field. time to rebuild this tool.
opening as 2.1.x dev line. I do still want to rebuild this (to SDC, general modernize). but time, as always....
overall, 'allowing empty' this is not a operation I want this model to have.
second note, patch does not have need tests.
pameeela → credited SKAUGHT → .
would you be able to outline the advantage of this hook? simply, what is your use-case that you need to alter the like that you can not 'use custom title' not be useful??
also: needs tests.
[#3344141]. ScrollTopCommand is now a core command.
have added composer file and adjusted module info for 10.1. -> 11. have tested on d11 locally