583 Results for the search: "#Mautic"

Well, I am programming PHP but I have absolutely no experience with Symphony and the Mautic infrastructure. At the moment I can assist and I think the mapping of the existing country and Region definitions with the new standard will be the most involving part of the project. I think I can contribute with this part if you have somebody else who can give me assistance with the coding.

This project is now completed and shipped in Mautic 7! Thanks to everyone for their great work and collaboration on this project!

Thanks for all the great work on this project folks! Really looking forward to seeing it coming into core in Mautic 7!

I think that the UI and reviews, ratings features are pretty much there from Ketu. It can be always improved, made prettier, more robust.

It's close to an alpha release. We just need to set up a paid Supabase instance that we could connect to the open Mautic PR so it could be tested properly.

I think there could be improvements made on the base that Ketu build last year. For example:
- Merge the plugins view with the marketplace view. Meaning the plugins could be configured from the marketplace
- Show what plugins are installed
- Show what plugins have an upgrade coming
- Perhaps even a command for automatic plugin upgrades
- Maybe even a preparation for Stripe integration for paid plugins and themes
- Get it released

They're different things, totally different proposals, level of freedom to create and context...

Knowing that 100% of all Mautic instances will ship with your theme and name is way more attractive than the _possibility_ of a user searching manually on the marketplace and founding your theme, then installing and etc...

This decision is strategic, aims to make donating themes reasonable, with the main goal of improving the user experience (the guidelines already suck a bit, let's not make things worse).

Another point is that we're probably unable to control quality and set guidelines (like 2, 3, 4, 8 and 11) for things in the Marketplace. Every barrier we place make things hard to move forward. A "not growing" project is a dying project. We don't want that. We need more people, companies and contributions.

Having the proposal here is also about changing the official documentation to embrace a permission to release good things into core. Right now, we have a sentence there telling that it's prohibited.

Agree with this proposal, It makes more sense to me that Mautic Themes should recognize authors. That's a great motivator to contribute with themes!

So the way core field groups are done now is with the translations. Esentially you have something like this:

[
'mautic.lead.field.group.core' => 'core',
'mautic.lead.field.group.social' => 'social',
'mautic.lead.field.group.personal' => 'personal',
'mautic.lead.field.group.professional' => 'professional'
]

You see the key in the above array is actually translation string, so when I was writing this plugin I tried to build it in a way so that it does not against existing code base, and instead tries to reuse as much as possible and does not touch things you do not absolutely have to touch. If I would not use translation approach I would have to modify templates as well where these groups are used.

So when you enter the field group in the plugin form, plugin actually takes what you enter as a display name and behind the scenese generates translation string similar to the ones you see above.

It is true that at the moment you can only add one translation for the group, but if there is interest we could add ability to the plugin to add more the one translation. That being said, I am not sure this adds much value since you do not really translate the field groups (by that logic you would also want to translate the custom fields labels, you just do not).

And when we use translations we also use translation cache, that is why the tasks related to cache were listed above.

Alias is something that I took from custom fields :), but I guess, I could make it work with the IDs (would have to check though, to not have any surprises). So it would look something like:

[
'mautic.lead.field.group.1' => '1',

]

Thanks for the suggestion. One thing to keep in mind is that when you reference field groups in custom plugins for example, like when you update the field, the code is easier to read if you have some descriptive name as oppose to just an ID (but that is just from the perspective of development of custom functionality).

For example:

$lead->getFieldValue('countryiso, 'mygroup');

looks way better, then:

$lead->getFieldValue('countryiso, '1');

Do we use translation approach (and do not touch lead/company templates, but we need to take care of the cache) or do we leave the translations out and update the templates?

My personal take is that I do not mind touching templates, but we should use some sort of cache to load this records due to performance, since field groups is something you typically setup once and then just use it, I do not think field groups change that often.

But I will do, what you decide is best :).

All of it sounds good!

The only thing I don't understand is the translation and cache. Why do we use translation for user-generated strings? We don't do that in other parts of Mautic, right? How would users translate the groups names if the group names should be translatable?

And, do we need aliases? IDs aren't good enough?

This sounds like a really helpful feature for users of Mautic who rely on ABM.

There might need to be some discussion and decision making on how to roll things up into the company - I know in the past there were some who really needed to keep the individual and company scoring separate, for example, and not just make the company score a roll-up of all individuals associated with it.

I'd recommend using the Debates feature to thrash out any details like that so that we can ensure we're inviting consultation on such changes.

I don't really see a need to change the naming of plugins. There are all kinds of different names for things like that, and plugins is fairly common. Drupal uses the term "Modules" for both features and integrations. "Connectors" could be another option, but that would only be for external services.

My vote would be to keep the name of Plugins (particularly with the technical considerations that John mentioned) but change how they're organized. The Plugins page could have multiple tabs for 'Core' plugins (maybe call that something like Features?) and Integrations. Companies hosting their own distributions of Mautic (e.g. Acquia, Webmecanik, Dropsolid, etc.) will also have their own plugins - and while they may handle availability of community-contributed plugins differently, those companies may want to clearly separate the plugins (features and/or integrations) that they've built and maintain vs. what's available from the community.

Mautic still haven't healed from the last renaming. Segments used to be called Lists, contacts used to be called leads. So it's very confusing in the code where some code is using the old terms and the new code is using the new terms. The biggest problem is on the database level as changing names of tables and columns is very time consuming and such migration would be done when Mautic is offline as the tables will be locked for hours or days.

Another issue is with APIs and webhooks. If there are services connected to Mautic via APIs or webhooks and we change one keyword to another then all those services must be changed to use the new keyword. So every renaming is very costly and will cause confusing many years in the future, perhaps during the whole lifetime of the project.

The plugins in the Plugins page are installed plugins. Most of them are core plugins. The product team is trying to remove the core plugins from the core as the usage is minimal and the maintenance cost for the core team is high. We've tried that for Mautic 4 but it was reverted as we wanted to firstly prepare the easy way to install plugins. That's where the marketplace came to be. It's still very immature as no company hosting Mautic really wants it. They install plugins differently and some do not support plugins at all. All companies also see it as a security risk to let users install 3rd party plugins. I want to say that the development of the marketplace is slow but there is some new movement with the GSoC students.

About the naming, the marketplace started to use Composer which is the standard tool to install dependencies in the PHP world. It has open repository of packages. So now we have the packages keyword in the marketplace. A package can be either plugin or a theme.

Then there are special kind of plugins called integrations. Those extend special integration interface that enables plugins to easily implement authentication to another system and even custom field mapping configuration. Perhaps that's what you call External Services? Can we call it integrations? But those are still plugins. In other words, integrations are subset of plugins. Plugins and themes are subset of packages.

Firstly, a huge thanks to everyone who has put a lot of effort into this proposal already, it's clearly been well researched and has been thought through from a lot of angles. Huge kudos to you all for taking this deep dive and identifying where Mautic needs to improve!

I think this would make a really great Community Initiative, especially seeing as you have already got several people who want to work on it and a clear scope as to what needs to be achieved.

Something to bear in mind is that not everybody is privacy-minded, so while I absolutely agree it would be awesome for Mautic to be the gold standard in that regard, there are a lot of folks who do want / need to collect some information that folks in Europe may not. So we should be mindful of that as we move forward with this, to not 'throw the baby out with the bathwater' and communicate clearly the impact of changes being made.

Mautic still needs to remain functional for the marketer, at the end of the day!

Firstly, a huge thanks to everyone who has put a lot of effort into this proposal already, it's clearly been well researched and has been thought through from a lot of angles. Huge kudos to you all for taking this deep dive and identifying where Mautic needs to improve!

I think this would make a really great Community Initiative, especially seeing as you have already got several people who want to work on it and a clear scope as to what needs to be achieved.

Something to bear in mind is that not everybody is privacy-minded, so while I absolutely agree it would be awesome for Mautic to be the gold standard in that regard, there are a lot of folks who do want / need to collect some information that folks in Europe may not. So we should be mindful of that as we move forward with this, to not 'throw the baby out with the bathwater' and communicate clearly the impact of changes being made.

Mautic still needs to remain functional for the marketer, at the end of the day!

Totally get your viewpoint here, but to be clear this is not something we'd be making from scratch - it's already been created by a business because they needed greater oversight of their cron jobs and where they were failing, and they wanted to contribute it to Mautic. So it's not taking any time that would be otherwise directed elsewhere, other than for the code review and testing.