Well that is beyond opinionated. Outlawing a perfectly fine spelling variant is creating a problem that does not exist in nature. 😀
Yay we have full passing tests!!! Thank you for this contribution.
Thank you for solving these issues.
Thank you skyriter for this fix.
Good idea. It is merged now so you should be clear.
Thank you for this contribution.
Thank you skyriter this is a helpful and appreciated contribution.
Thank you for getting the phpstan to be happy.
Fantastic spellerizing. Thank you for this contribution.
Fantastic work @Nidhi27. Thank you for all your work on this.
Thank you dmundra for this contribution. cheers.
Thank you dmundra. What a wonderfully helpful addition.
Thank you so much for this contribution dmundra.
Thank you @skyriter for this helpful contribution.
Thank you for reporting this @jastraat
THank you skyriter and jastraat. This is a big help.
Thank you for this contribution jastraat. It is a big help.
Thank you skyriter for this contribution. It will make my life so much easier.
Thank you @theloneliestmonk for this contribution. It is much appreciated. Thank you too @dmundra
That is strange. I am using this on Acquia without issues the only difference in the stack being PHP 8.2.
Crediting @capysara for finding this and mentioning it in Slack.
@ultimike
I don't know if it could be a case study... it is more of an idea that has not been put into practice yet. (Contrib First has been practiced, but not the IXP participants part). I'll discuss a blog post a bit more within CivicActions. Unfortunately the climate in the Federal workspace is not the same as it was a few months back.
As a maintainer of a bunch of modules, I find the tugboat previews very helpful and a large time savings. Your mileage may vary.
Is code updated when new code is pushed? If so are these new environments or continuations of the previous environment?
When the MR is updated, the Tugboat environment rebuilds automatically within a few minutes in the same environment (the url does not change).
In this basic form there is a decent amount of setup that still needs to be done from an admin before they can test much/any of TFA's code. Add an encryption key, setup an encryption profile (which requires an encryption module), before TFA can be enabled, add a user, add a token, etc. ... in my local lab I have multiple users, multiple tokens, multiple token types, user roles, and requirements setups configured to test most usage scenarios)
I don't know the specifics of what it takes to setup these items but assuming you are using drush commands or some other terminal commands, they could be run by adding them to the config.yml. Doing so means all co-maintainers and any new co-maintainers would have access to the power and benefit of your local lab type setup. Sounds like and easily achievable win to me.
Presumably some of that setup time could be reduced by configuring the environment inside the template.
100% accurate.
sometimes with a requirement for a breakpoint in XDEBUG.
Tugboat would not work for needing to test at xdebug breakpoints. I believe adding access to the environment terminal is on the roadmap, but xdebug is not. If you need that level of investigation then you'd still need your local. It comes up for me on occasion that I need to inspect patch solutions at that level, but it is fairly rare.
How often would users use this? How many that do use this it will perform an actual test rather than a "it loaded" test which provide us little to no validation.
This often depends on the issue being addressed. In this initial addition, there is not much to test other than "it loaded, and the module is enabled" After this is merged, on UX issues it can help people see the change visually or on multiple devices which screenshots can't really do. When you are working in your "lab" setup, how easy is it for you to preview the changes on your mobile device? Tugboat previews makes it very easy. It makes it easy for others, without extensive lab set-up to see it too.
Critically there is no encryption plugin installable through the UI which renders TFA impossible to setup and test inside of Tugboat.
This sounds like you've identified a new Feature request for the module. Maybe a test encryption plugin that only gets enabled via a drush command to make testing in general easier?
...but still possible noise for longer lived issues if users are closing/opening mr's to generate previews)
I have not found this to be the case. If someone has submitted a MR and the TugBoat environment expires, it is not usually the submitter that rebuilds it. It is usually the maintainer that rebuilds it right before reviewing it. Generally Drupal people are nice, they usually say "please" and "thank you" and they try not to create noise for maintainers. I also know that it is on the roadmap for the Tugboat implementation here on Drupal.org to be adding a link/button to rebuild them without needing to close and re-open or rebase the MR.
In closing, you are right adding tugboat without following up with a bit of additional setup would not gain much. But with a bit of additional setup added onto the tugboat config could make this very helpful.
CivicActions (via nerdstein's contributions) supported this module all the way back to 2014 right after its inception. It is a module we use on several large sites and wanted to give back to help make it easier to contribute to / support in the future.
Crediting ultimike for the idea.
This has been released with 8.x-1.12 →
Awesome. Thank you for playing "programming blind" with me. :)
I 'll get this merged and cut a release in a few minutes.
Sorry. I missed the two instances of the $queue.
I just pushed a fix.
Ok this should do it.
One more time please.
Woah... never seen that one before. I'll dig into it this evening.
If you force refresh that patch I think that should solve those errors.
And again thank you for testing this out because I do not have a current site using this module.
Thank you. I see the problem. working on a fix.
@richarddavies can you test the patch from this MR with your setup and let me know if it works?
https://git.drupalcode.org/project/govdelivery_bulletins/-/merge_request...
Interesting. I will push up a MR in a little while. But I will need you to tell me if solves the problem.
Thank you for reporting this.
It looks like the same issue that is described here https://www.jeffgeerling.com/blog/2019/rendering-twig-templates-programm...
The twig engine is not loaded during VBO.
Seems like adding the twig service as avia dependency injection is the right way to go and might solve this edge case.
That is a good point, @nidhi27. I think I'd prefer a list to a table. I think it is better for accessibility.
Thank you so much for this Nidhi27. It makes the experience so much better.
Thank you @nidhi27 for your work on this. It was very helpful.
Great question. I almost forgot what my intention was.
Example:
Let's say we have a content model document that is documenting the "article" content type (or vocabulary) When you view the document :
- If the pathauto module, is installed it would display the Pathauto pattern for articles"Pathauto pattern: article/[node:title]"
- The location should be below any custom fields on the document, but above the permissions table.
- If Pathauto is not installed, nothing would be output.
- If Pathauto is installed but there is no pattern for this content type, it would say "Pathauto pattern: No pattern set."
You can ignore my note in the issue to also do it for any title patterns. That solution may not be tied to just detecting one module being used..
Thank you so much @Nidhi27. I will take a look at this a little later today.
Released as 1.0.11 https://www.drupal.org/project/codit_batch_operations/releases/1.0.11 →
Thank you @capysara for working this through with me.
(repeating this Slack conversation here for context)
The initial branch brought the the batchScriptInterface into batchOperations, however that interface should only be applied to the actual Batch scripts. They are the ones that have to implement the interface. BatchOperations is more like an abstract class (probably ought to be). The BatchIperations class should only have to implement the parts of the interface that are optional, not all the non-optional ones. If we make it use the interface then the Custom BatchOperations don't have anything that they MUST implement.... which would cause a bunch of problems for people who need the interface to guide them on what MUST be provided in the script.
I just merged in a fix that will allow you to add something like
public function canBatchRun(): bool {
return TRUE;
}
to your BatchOperation and have it determine if it meets your conditions for processing the Batch when cron tries to run it.
@kellysmith thank you. Yes I worked initially with the Accessibility team and did a loose round of requirements gathering. I left off filters for host entity and for title mainly because there are less important. It is really easy on a View like this to completely overwhelm by filters for everything. So I was trying to be.a little selective. Keep in mind if any site determined that they needed to be able to search title, they could add the filter themselves later, or if it was important to filter by node VS taxonomy they could also add the filter. If you feel they are important, please call it out and we can add them.
I added a commit calling out what I suggested. We'll see if it works. It may take a few attempts.
Good question. Maybe of limited benefit, or might be a real help. I am not sure what additional you might need but this can be pretty easily extended by adding other calls for other modules (that are not official dependencies) by adding them like this line
https://git.drupalcode.org/project/migrate_boost/-/merge_requests/10/dif...
and then enabling by replicating this line
https://git.drupalcode.org/project/migrate_boost/-/merge_requests/10/dif...
Additionally whatever drush commands that need to be run can be added like this
https://git.drupalcode.org/project/migrate_boost/-/merge_requests/10/dif...
I am not sure exactly what would be helpful to your maintainership but off the top of my head it might look something like
- composer require pathato (because it is not a dependency but is part of your config install)
- composer require migrate_plus
- drush Enable migrate_plus
- Druah enable the submodule migrate_example
- drush run at least one of the example migrations.
This would give you an environment that has run a migration with migrate boost enabled. You would see in the terminal output (tugboat log) if there was an error. I am not sure what kind of things you would look for to validate that there were no problems introduced by migrate_boost.
Even without doing all the additional steps, it gives you clean environment where your module was just enabled. You can make sure it throws no errors when enabled or when looking at perms or anything else that might be relevant or is not missing a dependency.
Thank you jrockowitz for this contribution.
@capysara thank you for this contribution. I will release it today to you can be unblocked.
I am curious what service you needed to inject. If you think it would be useful to others I'd be happy to add it it to the base class.
@capysara, that is a good question. That change to final came in with some phpstan fixes here . Frankly I didn't understand phpstan's reason for calling it out at the time. Let me investigate this a bit more today (after I've had mee coffee). I am not opposed to changing it back like you've done. The part that is interesting and that I have not figured out yet is that phpstan originally called it out as needing to be final, but it is not re-flagging it on your commit. Makes me wonder if phpstan has fixed an overlay aggressive standard. I'll look into this some more today.
The preview environment will only exit for 5 days. (closing an re-opening an the MR will recreate it)
u: admin
p: admin
will get you in.
Interesting discovery. No I think we want menus to be documentable whether they are fieldable or not. Lots of sites have menus they would want to document even if they were not fieldable.
See comment and the error shown in #6.
Good question klausi
I got a little carried away adding this to all modules that CivicActions has ever supported. I was a bit on auto-pilot after doing a bunch of them and did this without thinking about coder's unique case of not actually being a module. So at this time it is probably not of any use to coder maintainers. However, I do know it is on the D.o / Tugboat integration roadmap to support terminal access to the tugboat instance, and in that case it might be more useful for coder maintainers and contributors.
This issue could either be
- parked until that feature becomes available
- merged without harm but no immediate usefulness to coder
- closed as not needed
This will also close 🐛 Can't install with composer Active
I think @swirt's idea should be part of the "IXP Best Practices" for hiring organizations documentation. @swirt and/or @chrisck - would one/both of you be willing to do that?
I am happy to contribute to the effort, but I am not sure what the request is. My comment is already on that issue. Are we creating a fork for documentation?
Yep definitely seems to be a duplicate. of 🐛 entity_generate result is ignored when the entity already exists Active
How it should work is that if you have menus defined, you should be able to create a CM Document that can describe any menu.
Example: If you had a "main" menu and an "FAQs" menu, you should be able to create a CM Document for the FAQ menu and then another CM Document for the main menu.
@nicholass I also encourage you to take the great suggestion you made in #5 and make it a separate issue. I would do it but I want you to get credit for it.
Hi @nicholass Funny meeting you here. ;)
This issue will get resolved by this issue
✨
Add tugboat previews
Active