bohart → credited artem_sylchuk → .
That worked perfectly for me, thanks!
bohart → credited artem_sylchuk → .
Thanks for catching that, fix is merged.
However the code there is confusing, the thread entity seems to be stored in the formState several times with different names, I think I'll create another issue for cleaning that up.
artem_sylchuk → made their first commit to this issue’s fork.
Nice catch! Thank you, merged.
artem_sylchuk → made their first commit to this issue’s fork.
Closed, thanks
That should be enough for now I think, thanks!
artem_sylchuk → made their first commit to this issue’s fork.
Awesome, thank you!
artem_sylchuk → made their first commit to this issue’s fork.
Private message had a config to hide the format selection that was confusing people.
That setting is removed now as preferable way to handle this is to use Drupal core configuration:
https://www.drupal.org/node/3318572 →
For core versions prior 10.1 the
https://www.drupal.org/project/allowed_formats →
had to be used.
Using WYSIWYG editors and allowing different media for drupal default textare is a topic of a basic Drupal configuration and isn't specific for Private Message as module uses the generic field type for it.
artem_sylchuk → made their first commit to this issue’s fork.
artem_sylchuk → made their first commit to this issue’s fork.
Thanks!
artem_sylchuk → made their first commit to this issue’s fork.
artem_sylchuk → made their first commit to this issue’s fork.
Thanks!
Let's get this finally merged
Thanks!
artem_sylchuk → made their first commit to this issue’s fork.
Drupal 9 is no longer supported so I think we can safely move drush services deifinition to the general services.yml file.
artem_sylchuk → made their first commit to this issue’s fork.
Thank you for updating that code!
artem_sylchuk → made their first commit to this issue’s fork.
Good catch, thanks for your massive work!
artem_sylchuk → made their first commit to this issue’s fork.
Looks good for me, thanks!
artem_sylchuk → made their first commit to this issue’s fork.
I hope that additional mesage on the module install will help to not miss the needed steps of the module configuration. The readme already contains mention of the needed steps.
artem_sylchuk → made their first commit to this issue’s fork.
Awesome, thanks!
artem_sylchuk → made their first commit to this issue’s fork.
Looks good, thanks!
artem_sylchuk → made their first commit to this issue’s fork.
Hope that will help
artem_sylchuk → made their first commit to this issue’s fork.
Awesome work, thank you guys!
Looks good, thanks!
Merged, thanks!
artem_sylchuk → made their first commit to this issue’s fork.
Thanks for checking that, marking as fixed
Awesome work! Merged, thanks!
artem_sylchuk → changed the visibility of the branch 8.x-2.x to hidden.
Looks good, thanks!
artem_sylchuk → made their first commit to this issue’s fork.
Thank you, looks good for me, merged.
artem_sylchuk → made their first commit to this issue’s fork.
Its mergable with latest dev (at least gitlab says so), however it brings massive UX change and upgrade path is questionable so it is doubtable that I'll merge it the way it is now. However I think eventually having 2 separate private message types is the proper way to go.
artem_sylchuk → made their first commit to this issue’s fork.
artem_sylchuk → changed the visibility of the branch 2942602-unable-to-create to hidden.
Going to review this, however I see that at least at one place the context passed to once() is wrong
I suppose there is no more to fix here. Except some documentation maybe
It seems it is already fixed in 3.x
Can't reproduce on the recent version of the module.
Code referenced here is no longer present in the supported branch.
That is doable with using some of the drupal apis (defining a route in a custom module + some preprocess functions), however I don't think it is still relevant after 5 years.
No chance for this to happen anytime soon.
Don't think it is still relevant after the 5+ years.
1.x won't receive any more updates.
I believe it is fixed in 3.x
Don't think it is happening anytime soon
1.x isn't going to receive any updates.
Unfortunately 1.x is no longer supported and I'm not sure if anything of that can be easily used in 3.x. CLosing as outdated
That might be a cool feature, but years passed since its creation and there is no comments here. Closing as 1.x branch is no longer supported.
1.x is no longer supported, closing as outdated.
1.x is no longer supported, closing as outdated.
I think the main idea of the Message module is a bit different from exchanging the messages between users. They define the "templates" with token support to be used as some kind of events log. It perfectly fits the idea of system notifications but I think that it is not ideal when you need to exchange messages between several recepients.
In any case private_message has some kind of integration with message_notify module for notifications and it this hangs open for 5 years without any changes so don't think that anyone plans any work here.
I'd love to see that as the separate module and probably the complexity of the proposed solution can be reduced, I see some ban entity permissions that probably could be omitted.
But as long as this patch is around for really long I suppose a lot of users has it applied and trying to implement it in a different way will result in the painful upgrade path for ones who used the patch before it was merged.
So merged it as is to 3.x, but probably we need a way to allow disabling this feature. Right now it is possible to hide the ban links, but access to the ban pages can't be restricted using permissions. Don't want to postpone this issue for another year or so because of that.
Hi @earthangelconsulting,
The biggest breaking change was introduced in 8.x-2.x-beta17.
In 3.0.0-beta2 there was some refactor and the notification sub-system was moved to the separate module.
It can cause problems with private_message_update_8007. I wasn't able to reproduce the problem but please let me know if it happens to you.
(As a workaround you can try skipping that update entirely by placing the return; statement as the first line of private_message_update_8007)
If you already have the 8.x-2.x-beta17 version then it should be pretty safe to upgrade.
But obviously it is recommended to create the database dump before procceeding and running the update on the dev environment first.
*running the update.php or drush updb is thre required step to update*
If you have the version before beta17 then the process may be more complicated. The update hooks should do all the needed changes, however the time of update depends on your database size. You may need to check what goes in private_message_update_8005() before running the update.
Hope that helps, thanks.
Please feel free to re-open if you face any issues during the update.
+
Oh, my bad.
Thanks for pointing that out @oadaeh!
Updated the patch.
The old patch no longer applies, here is the re-roll attempt
Attempted to re-roll the patch as it doesn't apply to the dev version anymore
Patch from #21 applies clearly, however it includes the irrelevant part with automatted converting the ->link() to ->toLink()->toString() by rector.
Fixed that and attached the interdiff.
I tried to fix the MR, but it includes a lot of uneeded changes in commits history and it doesn't seem I can create a new branch for some reason.
So I hope patch is fine too.
Created the MR with the fix
artem_sylchuk → created an issue.
Hi @heddn,
I've just opened the issue queue going to finally deal with the D10 realease and found that you already did that.
Thank you very much!
Sorry everyone that it took so long.
I suppose this one should be closed too