Alex Sirota
My feedback
119 results found
-
6 votes
An error occurred while saving the comment -
18 votes
-
83 votes
An error occurred while saving the comment There is a potential issue with the way Wild Apricot currently delivers emails. It appears that the system is configured to "spoof" a sender address. When using a custom domain DKIM and SPF records are added to DNS for the custom domain but that does not always ensure successful email deliverability.
What could be improved is if an undeliverable email can be optionally re-delivered through a functioning real mailbox (rather than spoofing). This has several pieces of added value:
1. Emails will be delivered on behalf of a real mailbox that has storage space and hopefully good email profile. That mailbox must be configured under the custom domain name applied.
2. Because emails are sent through the SMTP server of the mailbox email deliverability should increase.
3. This could be an option to improve email deliverability as spam filters prefer real mailboxes as senders rather than the sender and from emails being different (as is the case now).
Because some hosts do not want hundreds of emails sent through an SMTP server there may be some constraints here. Also there is an added cost for a higher level of email deliverability that may be desired.
In concordance of this request maybe it should be possible deliver an undeliverable email through an alternate SMTP server that is configured optionally by the Wild Apricot admin.
-
8 votes
-
15 votes
-
13 votes
-
58 votes
An error occurred while saving the comment We are working with a WA customer to help them integrate with AffiliateWP, a popular WordPress plugin with a ton of affiliate features/dashboards/coupons. There are multiple integrations with various systems in the WordPress ecosystem, but not Wild Apricot. I am looking to find out how to "inject" an affiliate code into the member subscription/join workflow. It appears that even adding a custom HTML widget on the Membership level change system page wouldn't work since we need to add it to the successful completion page and that does not seem to be accessible from the system pages editor.
Even if that were possible though, still the membership renewal has to have an affliate code inserted via the call via a search argument or as part of the browser session.
And then the final custom HTML would fire a JS back to the affiliateWP plugin to record a completed transaction, but I see multiple barriers:
1. How to inject the affiliate code so WP process doesn't reject it and uses it.
eg: https://newpathconsulting.wildapricot.org/Sys/MembershipLevelChange?affiliatecode=123
Seems to work but the search arg is lost on the next step.
2. The call back on the successful completion page.
I can only think of a theme override would be required to modify and support the injection and call back process to introduce the necessary scaffolding to support the call/callback of the affiliate process coming from AffilateWP powered WordPress site.
Another approach could be using Javascript to collect the inbound search arg on the initiall call, store the serach argument in a session and then load it up on the successful completion page, but again that specific page is in accessible to insert code into unless theme overrides are used (I imagine).
Maybe I am thinking about this wrong though. And maybe the mechanism is wrong.
Even a simple affiliate program with ability to record codes like discount codes and recording successful transactions in WA would be great. The requirements are quite simple.
1. Designate a code and record information for the affiliate program owner
2. When the code is recorded on the inbound call to the member registration system pick it up and on successful completion record a successful completion of a registration.Initially this could be used only for new subscriptions (not renewals, or recurring levels).
Depending on an external referral system to do this can be cumbersome and entail new costs/dependencies that are probably overkill for most people. Most are looking for a simple counter to compensate the affiliates based on simple math (percentage of the fee or a flat fee). This could be done all manually outside of WA since most affiliate programs are not that ambitious.
-
29 votes
An error occurred while saving the comment New customers who don't have experience embedding really lose it here. Especially nice formatting doesn't work. I think a better approach would be to have gadgets for video and audio so they can be placed anywhere without worrying about formatting.
-
136 votes
An error occurred while saving the comment **** why don't you collect this information as part of the member profile? That way it can always be updated on renewals too or left as is.
An error occurred while saving the comment What is the current polls/surveys tool missing to address your needs CGD59? https://gethelp.wildapricot.com/en/articles/1582
-
50 votes
An error occurred while saving the comment Another twist to the need for duplicating events -- when duplicating an event you may wish to optionally change the start/end date and time so that when an event is duplicated you can on the fly duplicate the event but bump to a future date.
Event duplication should also have an option to duplicate published events and copy their settings for audiences. So if it is restricted and already taking registrations, a duplication should KEEP the settings as is. Currently a duplicate event is automatically disabled and set for admin only. I can see why this may be a desired behaviour but if you are using the duplicate event as an event template, you'd want ALL the settings to be exactly duplicated and just push the date to a future (or in theory past) date and time.
-
74 votes
An error occurred while saving the comment I have been wracking my brain on how to work around elegantly Wild Apricot's configuration to accomplish the idea of a "master" site and subsites all within 1 Wild Apricot instance.
1) The database can be configured to have either a chapter assignment attribute OR a different set of membership levels for each chapter.
Using the database field approach one can register through a central, agreed upon set of membership levels consistent for ALL chapters (or at least the majority) and then the member records via drop down or radio button which chapter they are assigning themselves to. You can do some interesting things like being assigned (and pay via calculated charge membership field) to multiple chapters if you want. The MAJOR issue with this is that page level access control CANNOT be set with saved searches so membership groups have to be used instead. I do believe membership groups CAN be set on registration or renewal but cannot be automatically defaulted to a set level. This is an issue that could be solved with some page level Javascript (a very small hack).
Using membership levels is another approach where each chapter derives their own set of membership levels from a master set and then has a large degree of configurability. Membership levels are the chapter identifiers then.
Access control works seamlessly in the website with membership levels.
2) All access control to websites can be managed via membership level or the membership group and unsurprisingly this is the easiest and best fit. Chapters can have their own page templates derived from a master set of templates and the "subsites" can be quite rich with their own set of controls.
Escalation has to happen to a master website coordinator to make new pages or changes to page templates. This may be a *good* thing!
3) The events system has to use membership level/groups based on decision in 1 OR instead use the tagging system. Tagging system can be fragile and leak events into wrong chapters.
The main issue here is that any administrator with event management rights (or full admin) can see all the events and has to be adept at finding and managing their own events. Lots of chapters means LOTS of events. The upside is that people can copy event ideas from each other using duplicate but the event UI can become a mess. On the other hand with adequate training and policies this *could* work.
Events access control via gadgets show the appropriate events to each subsite chapter, with a BIG plus that events across the whole org seamlessly float up to a master event calendar.
4) The payment gateway limitation is the *single biggest* roadblock. Since only 1 currency and 1 payment gateway per account is allowed, the owner of the payment gateway has to be responsible for "doling" out funds to each chapter using a very well defined identifier. This must happen in the reporting on the payment gateway. Most (if not all payment gateways) support ONLY 1 bank account so this must be done OUTSIDE of the payment gateway. This is a show stopper.
If Affinipay supported multiple bank accounts for withdrawal based on a tag, a single payment gateway would be ok as long as an indicator for every transaction showed where the transaction goes (HQ, chapter 1, 2 etc) and if the payment gateway could just dump money into the right account, financial reporting could support the reconciliation effort.
Saving costs of multiple payment gateway setups and administration as well as single point oversight of all financials could be good (unless chapters didn't trust each other).
An error occurred while saving the comment 5) Reporting can be done in 1 site with membership summary quite well IF and ONLY IF the membership levels are selected for each chapter (described in 1). If a consistent set of chapters with calculated charge fields are used for all chapters, that's even better. The Excel Dashboard we adapted from Wild Apricot API samples can be effectively used for custom rollup rerpoting.
6) Training and operational excellence is a MUST in a single site multi-chapter Wild Apricot system. You have to do things correctly in terms of adding a chapter, adding pages, inheriting membership levels for a new chapter, modification of existing levels.
Setting up 1 set of levels seems like a better way to go but that assumes a business model transformation across all chapters which may not be realistic.
It seems doable, but the payment gateway roadblock seems to be the thing that is the most critical to resolve, whereas the others are not so bad.
Setting up 60 chapters individually with cloning and then reporting across them all seems great, but financially it just doesn't scale because the per contact cost at the smaller payment levels is dramatically more than at the 15k+ levels. The larger the org the less appealing a multi-site approach looks and the more difficult it is to manage.
I can see the light at the end of the tunnel if the Payment Gateway issue is resolved, honestly speaking.
-
106 votes
An error occurred while saving the comment Include export contacts logging as well to track who/when/and what fields where exported using the Export feature, please.
-
35 votes
An error occurred while saving the comment As much as it would be ideal to have a link in a menu to link to an external page, it's not best practice from a usability perspective. Also search engines may penalize your site if you have lots of menu based links that redirect to external sites. This is how spam farms tend to work and how they try to game search engines.
Best practice is to have a page on the site that links off to the remote page, but have the menu load the page locally on the site instructing the visitor to link to another site.
It sounds in principle like it is a good way to "shortcut" the 2 step process of a local page linking off to another page, but it is best practice to link off a page, rather than linking directly offsite on a navigation menu. Remember when visitors use your website they expect navigation menus to take you to another page on your site rather than offsite.
-
100 votes
An error occurred while saving the comment Just an aside -- database hygiene is always an issue even in the most complex and expensive products. There is always a way people can break validation with ingenious lack of information or purposely provide invalid data. Until a feature is available built in, Excel exports of problematic fields along with User ID can be used to bulk clean up data.
There are great Excel formulas that are easier to implement than regular expressions (many don't know REGEX patterns and directives). These formulas can be used to "clean up" data using built in Excel formatting rules for phone numbers, formulas like MATCH, LEFT, MID and RIGHT and data transformation tools like VLOOKUP, IFS and other means to convert values based on specific input. It takes some Excel smarts, but once you have a good workbench in Excel you can clean up data all day long :)
https://xltools.net/data-cleansing-in-excel/
https://support.office.com/en-us/article/top-ten-ways-to-clean-your-data-2844b620-677c-47a7-ac3e-c2e157d1db19 -
74 votes
An error occurred while saving the comment Support for EFT payments like Interac all over the world would be a terrific value add for WA Payments! +1
An error occurred while saving the comment I have a potential customer who called me looking for this feature in particular with authorize.net or stripe both which support ACH/echecks.
I was thinking maybe this could be implemented by just turning off online payments and recording the banking info as part of a profile so when a submission comes in, someone goes manually into the profile and manually posts the data to the check clearing services. Of course automated passing of data to authorize.net would be better, but I am looking for cheap and cheerful solutions until an automated approach works.
-
12 votes
An error occurred while saving the comment I have seen this be a common complaint as well. There should be a way to collect a subset of the common fields for Guest registration and collect a different set for member registrants.
-
29 votes
An error occurred while saving the comment The need also exists to renew for just the current "season" and not renew for a subsequent season. The current renewal policy of allowing to renew 1 season ahead should allow to turn off renewals for 1 season ahead completely.
The issue with renewals for 1 season ahead has to do with financial record keeping and some sports/seasonal club do not want to allow renewals for anything but the current season.
-
9 votes
An error occurred while saving the comment A few comments here -- export functionality is a must, as copy and paste is rather cumbersome. An import of the WordPress XML files could be a nice addition.
The main issue is that the new URL format must be established during the import to ensure link names are consistent in the new ** site.
Having an import from WordPress feature would go a long way to fixing this.
-
8 votes
An error occurred while saving the comment It is possible to use Custom HTML to assign page template level CSS that is inherited by the pages that use it. Here's how to set a page template level BODY tag change to swap out the background image:
<style>
body { background-image: url(https://newpathconsulting.wildapricot.org/resources/Theme/template_backgroundimages/imageWA.png); background-size: cover; background-repeat: unset; background-attachment: fixed; background-color: navajowhite; background-blend-mode: unset; }</style>What would be nicer is to be able to assign a full tag like this in a Custom CSS settings of a page template. Inline styles currently are only available for gadgets so it would be ideal to be able to add this code on the settings of the page template, just like they could be done on a page.
-
6 votes
An error occurred while saving the comment If you're going to support the ability to create a link field why not just go full route and support an HTML field which allows the embedding of a subset of HTML code like <a> <strong> <a href> some formatting and also <embed> tags. <img>
This would enable you to put all sorts of content into the membership field and enable rich media to be available. This will also solve the issue of profile photos not being large enough since you can create a Photo album.
I daresay putting a field like this in will actually let you design a more custom profile page without having to modify the underlying template in some cases.
){kind=link}
A few other notes on this -- one should allow a decimal point in the extra charge calculation to allow fractions. We use this field with a x 1.00 multiplier to collect donations as part of a membership. If you want to collect a 182.42 membership you can enter 182.42 into the extra charge calculation field but decimal points don't work so we need to run down and edit in the invoice system afterwards to add the remaining amount. This doesn't support the ongoing ability for the member to self-renew with the exact amount.