CiviCRM Community Forums (archive)

We're looking to pay a developer to help with some custom integration with CiviCRM in Joomla 1.7 (soon to be 2.5). YOu may not even need to know Joomla programming. We're working with an event component developer and a mailer developer (ACY Mailer) to connect their components to CiviCRM. Phase 1 of the ACY mailer is already done (polling groups and tags into ACY to send a batch email), but the ACY guys need help with Phase 2 (sending search results from CiviCRM over into ACY for bulk mailing).

We also may need someone to help us migrate our huge Endis/Insight database over into CiviCRM correctly. We can do a big SQL dump, but it would need to be cleaned up and then CiviCRM would need to be set up to take all that information (we've spoken to one developer so far about this but haven't made any decisions yet).

Lastly, we're having an event registration programmer modify his system to talk to CiviCRM and will likely need someone to work with him who knows the APIS.

On a side note...why are we bypassing the event and mailer functions? Well...frankly we find them lacking, and instead of having someone hack up CiviCRM, we'd rather have some custom components made for Joomla that simply talk to Civi...but we need someone with a really good, solid understanding of the inner workings of CiviCRM to help. Joomla experience is a plus since we assume it interfaces with CiviCRM differently than Drupal.

Again, this is a paying job and we have a good sized budget for the whole thing, but we need to get things moving so we can get off our old system by mid June.

thanks!

Can CiviCRM Mail pull in Joomla content (including module content and zoo content?). This is the main reason we're using ACY. Their new CiviCRM filter is pretty slick, we just need someone to help them make the other plugin.

As far as Events...the system just seemed clunky, and we didn't want to be forced to work within the confines of the system. The credit card is taken FIRST, which makes no sense to us. There's no discounting system. The set up isn't really all that easy for basic users (whereas, we're starting with the DTRegister Joomla component and it's really easy to dupe an event, change all the emails, add a custom field, etc).

We started out having someone mod CiviEvent for us, but there were certain things that would have just been too difficult or cost prohibitive to mod...and since we personally don't know what the ramifications of having a REALLY custom CiviCRM events module (what happens when we want to upgrade?), it made more sense to use an external events system and have it simply talk to CiviCRM. It could be that there's a way to do what we wanted in CiviEvent, but our original consultant (who is too busy right now to help us out on this new stuff) was going to have to really hack things up and spend hours and hours modding the system to get us what we wanted.

Instead, we're looking at paying the guy who makes DT Register to add new features to his component, and then build a bridge plugin that will sync it to CiviCRM. He'll likely release this into his commercial version...and trust me, it's got a heck of a lot more features than CiviEvent.

Again, it's very possible we could have had someone make an alternate version of CiviEvent for us, but we only have what our original consultant told us to go by, we're not CiviCRM experts.

So a couple of thoughts and comments:

1. I do agree on the points xavier raised

2. Yes, CiviEvent can be improved significantly and it will be over time. Its a lot better today than it was a year go and will be a lot better a year from now

3. The discounting module is available for drupal. So there is code for it already. The joomla world did not seem interested in helping with the make it happen and hence it was not ported over

4. There was also a drupal module to pull in node content, assemble a newsletter and send it via civimail. this however did not get enough traction and died an early death.

Bottom line, if the joomla community want to see better integration with joomla, they need to work with the broader civicrm community and each other to make it happen in an open source manner.

lobo

If we add all our phases of development here's the kind of registration system we need (some features are already in CiviEvent):

-Credit card asked for at the end
-no single or group function, and no "how many people" function, it would simply let you click on "Add another Registrant" or "add another married couple" sort of like a "ticket" type, but the system wouldn't need to know how many at the start, you'd just keep clicking "add another..." until you've added them all. We need the ability in the future to make several kinds of prices, such as Add another Adult, Add another Child, Add another Youth, etc.
-some kind of function so we can track or offer married couple discounts.
-ability to limit the registration to 1 (okay, call it a single if you want) so we can sell webcast access. In addition we need:
-ability to tie payer/registrant (we use it on singles only) to a joomla group. There is a plugin to sync civi groups to joomla groups, so this may already work without any modification
-Discount system that can be controlled so that it can be applied or ignored when group rates are reached. Also, the married couple discount needs to do the same thing. We also have special unique codes that each of our partners uses. Those need to be stackable on EVERY discount, including groups. It's an annoying system, but it's what our events people are used to, so we have to account for all variables there, and it needs to have a decent gui and not some xml file to be set up
-we need to be able to allow coupon codes to be entered PER registrant instead of the entire order
-We need to be able to make sure the registrants are put in a group (or tagged) but NOT the payer
-we need an automatic early bird price system
-we want conditional fields without having to learn javascript in order to create them. DTRegister does this beautifully. You can choose to hide a field and only show it if the user clicks on something (like a YES box).
-We need the ability to have fee fields to upsell items, both on a per event and a per registrant level
-we need the ability to tie any field to a group or tag in Civi, so that if we upsell or ask them to check a box, it will put them in a group or tag them.
-We need to be able to choose if a fee field gets discounted or not for groups or coupons
-Ability to create and charge for registrations from the back end
-It would be great to have a running total down the side of the page or at the bottom near the "add another" buttons but on the right side (buttons on the left). So at each step the user sees the total.

-long term, we'd love to have a secure wallet, so the user can come back in and do a 1 click check out, or so we can hold the registrations, fix or edit them and then run them. Our current system does this, but it's Endis, and it's hosted in England. I have no idea if it's even PCI compliant or what it would take to do this and still be compliant. Hopefully it's part of the Authorize.net API, but we don't know for sure.


There are more, smaller features, but I'd have to scour my list to put them all in. DTRegister does a bunch of this, but doesn't talk to Civi at all. We've already got it running, just without some of the features, and we're manually syncing records to CiviCRM (we only flipped it on for a few small events).

So, again, if someone can literally write EXACTLY what we need into CiviEvent that's fine, but I don't know what would happen when the next update to CiviCRM comes out, where as, if the DTDevelopment guy writes some connector plugins, he'd just have to adjust them for a civi update. He plans on rolling probably all of these features into the commercial version, so we wouldn't be stuck with a custom one off of his component either.

I'm not against switching back though, but we'd need to be SURE we weren't getting stuck in a place where we couldn't update Civi without major rewrites. I have no idea how putting new things back in the core works, but I assume you have an approval process? What if no one cares about the features we want but us? You can see where we're stuck.