I am still around, just have been quite busy with primary work. I would certainly consider additional maintainers but need to look at where things are and make a plan.
Bear with me as I do so. thanks!
Things to consider for testing:
- Are these buttons enabled by default?
- How do these affect backwards compatibility with existing installs?
I would worry a big change like this might cause issues with existing installations. Could this be an add-on submodule and still achieve the same effect?
Scope issues:
I would consider breaking this up into smaller blocks. The a11y changes especially are important, and would consider them sooner over a new feature add like the added buttons. Or even consider this whole thing as a v2 of the module. (this would also be safe for existing installs) and backporting the a11y stuff, specifically to the 1.x branch.
Choosing not to address the seemingly confrontational nature of the responses here by the maintainer, but I would point to the DCOC → to remind folks that they do apply and be mindful of others who choose to participate.
Blocking a Drupal Security Policy (DSP) validation for new and maintained versions of a dependant library behind a "paywall" might not be in keeping with recommended practices within the DSP or even good maintainership. I'd be very curious for the DSP folks to weigh in here on what would be considered best practices here.
Having previously tried to use this module, I ended up switching to FC v6 via a custom implementation and have noticed the implementation of v5 and v6 are very different.
I would be more inclined to believe that the task related to upgrading to v6 properly is a major effort that the maintainer doesn't have the time or resources to undertake. Which is understandable, however, this comes across as a bit poor-taste to make this a hill to die on. Having two major versions of a module, one covered by DSP and any future (major) versions not, comes across as confusing and reduces confidence in the overall project.
You're certainly free to do whatever you want with your modules, as long as you are following the licenses and practices that govern Drupal as a whole.
However, I, for one, would not. Seeing what happens to other "Freemium" modules in the Drupal sphere, and the utter cesspool that WordPress's ecosystem is with the same, it's not something I encourage here.
There are other ways to support yourself, including sponsorships etc within the community. I am not sure what you're hoping to get out of it, mind you.
Just my own opinion on the matter.
Should the README also be updated to include an overview of the drush command, especially since it's being enhanced here?
Change merged into 2.x branch.
Will have a look, thanks!
I appreciate the effort, but I am also inclined to agree with the others.
Mastodon provides methods to identify the community and properly attribute, I think it would make more sense to build that detection scheme.
I think the best way to approach it would be two-fold:
Do a regex pattern to see if the entered URL contains the @ symbol as part of the last URL segment. If so, do a query against the URL to get information on the Mastodon instance to validate it. See #4
I think for the most part, it makes more sense to just render the link with a Generic “Mastodon” link title. This avoids issues with how to visualize the disparate instances names and configurations.
We can, still, choose to specially treat the Drupal Community Mastodon instance the same way with the link text as “Mastodon (drupal.community)” to call it out specifically. This would also be useful if a user were to have more than one Mastodon link in their profile.
Mine is also not updated - but it is a drupal.community url
Updated the note announcing the availability of the module in core along with links to the Experimental projects docs.
Closing as outdated, and the 8.x-1.x branch will be considered minimally maintained and soon to be deprecated.
If there is value for the 2.x branch, please re-open and provide feedback for improvement.
Closing as outdated, and the 8.x-1.x branch will be considered minimally maintained and soon to be deprecated.
If there is value for the 2.x branch, please re-open and provide feedback for improvement.
Closing as outdated, and the 8.x-1.x branch will be considered minimally maintained and soon to be deprecated.
If there is value for the 2.x branch, please re-open and provide feedback for improvement.
Moving this to the 2.x branch to be reviewed. (Will backport to the 8.x-1.x branch if nessesary)
This is still an issue that has not been fixed?
Closing as outdated, and the 8.x-1.x branch will be considered minimally maintained and soon to be deprecated.
If there is value for the 2.x branch, please re-open and provide feedback for improvement.
Is still an issue? And does this also happen on the 2.x version?
Closing as outdated, and the 8.x-1.x branch will be considered minimally maintained and soon to be deprecated.
If there is value for the 2.x branch, please re-open and provide feedback for improvement.
Closing as outdated, and the 8.x-1.x branch will be considered minimally maintained and soon to be deprecated.
If there is value for the 2.x branch, please re-open and provide feedback for improvement.
Moving this to the 2.x branch as this could still be relevant and should be looked at.
Closing as outdated, and the 8.x-1.x branch will be considered minimally maintained and soon to be deprecated.
If there is value for the 2.x branch, please re-open and provide feedback for improvement.
Closing as outdated, and the 8.x-1.x branch will be considered minimally maintained and soon to be deprecated.
If there is value for the 2.x branch, please re-open and provide feedback for improvement.
Closing as outdated, and the 8.x-1.x branch will be considered minimally maintained and soon to be deprecated.
If there is value for the 2.x branch, please re-open and provide feedback for improvement.
Closing as outdated, and the 8.x-1.x branch will be considered minimally maintained and soon to be deprecated.
If there is value for the 2.x branch, please re-open and provide feedback for improvement.
Closing as outdated, and the 8.x-1.x branch will be considered minimally maintained and soon to be deprecated.
If there is value for the 2.x branch, please re-open and provide feedback for improvement.
Closing as outdated, and the 8.x-1.x branch will be considered minimally maintained and soon to be deprecated.
If there is value for the 2.x branch, please re-open and provide feedback for improvement.
mikeohara → made their first commit to this issue’s fork.
It's really around trying to keep this to core behaviour if I can. There are plenty of times when the select list will be too long to effectively parse. Even on moderately complex sites. We could have it so that if the list of views is beyond a certain size it uses autocomplete, but I think adding that logic, or even making it a user choice, adds complexity which could be necessary.
I am fine with leaving it either way. But I can see where OP was struggling, and it does make some sense to introduce this as an improvement.
I created the first pass at a super dirty implementation of a views filter to allow users to filter a view on whether the results are protected pages or not. (see merge request !11)
It basically just extends the InOperator filter and allows a user to filter all results or specific node ids (pages). You can also flip to include or exclude these results.
Currently, it leverages the loadAllProtectedPages() storage method to get the list of internal route paths, and then iterates them into an array. Views can then do a filter from that.
I hope this helps frame a solution, but this does seem, in limited testing on my end for my own needs, to solve the problem.
mikeohara → made their first commit to this issue’s fork.
MR accepted and merged to dev, thank you.
Will be included in our next release.
MR accepted and merged to dev, thank you.
Will be included in our next release.
mikeohara → made their first commit to this issue’s fork.
So I finally had a moment to work on this. Keeping with the concept I had of not introducing additional 3rd party dependencies outside core, I converted the select list into an autocomplete Ajax field.
This appears to solve the issue of making the selection of views more streamlined and easier to parse:
1: Initial Display
2: Search behaviour
3: Selection
Additional enhancements could include filtering out views that do not act on taxonomies/vocabularies, but I am not entirely sure if that is useful or not, and was not initially able to find a way to easily filter that.
Otherwise, any feedback, contributions to this work is appreciated.
2.0.0-alpha1 was released today as a move-forward version for D9/10+. This issue can be closed
Bug fixed in 2.0.x-dev
D10 support added to the 2.0.x branch.
Fixed in the 2.0.x branch and release!
Fixed in 1.x and pushing for 2.0.x for D10 release.
This was merged into 1.x branch and will be ported into 2.0.x branch as well.
Thank you for your contribution.
This was previously merged into the 1.x branch on Oct 13, 2021. Closing for housekeeping.
README changes accepted and merged into 1.x will also be incorporated into 2.x branch.
mikeohara → made their first commit to this issue’s fork.
mikeohara → made their first commit to this issue’s fork.