First Automatic Friends - Joomla Extension

A Guide to Setting Up First Automatic Friends for a Joomla Community

This guide to First Automatic Friends will help you understand how automatic friend connections are created at registration, prepare a Joomla test environment with a supported social extension, build a safe welcome workflow, and verify exactly what type of connection new members receive. Rather than repeating a product description, it walks through the practical path from defining community rules to test registrations and diagnosing edge cases.

First Automatic Friends is a small user extension for Joomla social communities. According to the developer's description, it processes the creation of a new user and can create a friend connection with one, several, or all specified accounts. Depending on the connected social system, the outcome may be an already confirmed friendship or a friend request. JomSocial is also described as supporting a custom message in the request. These features may sound simple, but they affect an important part of the community: first impressions, privacy expectations, the workload placed on mentor accounts, and the proper interaction between Joomla and Community Builder, JomSocial, or EasySocial.

Automatic friendship should not be treated as a replacement for a welcome email, moderation, or genuine introductions. Its useful role is more specific: after registering, a new person does not have to search for their first contacts from an empty profile. An administrator selects trusted profiles in advance - for example, an editorial account, a group of community coordinators, or an official club profile - and makes the community easier to navigate from the start. Automatically connecting a newcomer with every existing user produces a very different outcome and social burden. Choose the rule first, then enable the extension.

What an Automatic First Connection Solves

New members of a social site usually face two issues. First, their profile looks empty immediately after registration: there are no contacts, notifications, or obvious reason to return. Second, the administration may want to separate official help channels from random personal profiles. First Automatic Friends helps establish an initial connection through one repeatable rule at the moment Joomla creates a user. It does not match people by interests or generate smart recommendations. Its value lies in predictability: the same principle is applied to every new registration.

It is useful to name the outcome in the same way a member will see it. In one community, it may be a request from a profile called "Community Team"; in another, an already confirmed connection with two mentors; in a third, a set of connections with official section accounts. That wording determines the technical configuration, the welcome text, and the later verification process. If the team cannot explain to a new user why a particular profile appears among their friends, the automation rule is not ready to be enabled.

Three Use Cases Where the Rule Makes Sense

An official starting point. A club, learning project, or private community has one team profile. After registering, a member sees that profile and understands where to ask for guidance. In this case, it is best to limit the rule to one official account. The administrator should verify that the profile is active, clearly named, configured with the right visibility settings, and not used by an employee for personal conversations.

A small group of community coordinators. In a learning or local community, a newcomer may benefit from seeing two or three pre-approved profiles: an instructor, a moderator, and a support account. This approach works when every coordinator is ready to receive new questions. Do not enable it automatically merely because the system includes several administrators: a Joomla technical role does not always match the role of the person who communicates with newcomers.

A private network with an explicit mutual-introduction rule. Connecting users with everyone else makes sense only in a small group where the rules promise this and members expect mutual visibility. On a growing or public site, this option quickly creates noise. The number of new relationships grows with the number of registrations, not with the actual need for introductions. In most cases, it is wiser to leave it disabled and organize introductions through groups, activity, or manual invitations.

Who This Extension Is For, and When to Choose Another Approach

First Automatic Friends is suitable for a site owner who already uses one of the listed social components and wants to direct new users to a clear first contact. It is a tool for an administrator or community manager, not an ordinary visitor: the rule runs in the background during registration. It is especially useful where a consistent onboarding experience matters more than individualized recommendations.

The extension is unnecessary if a site uses Joomla only as a directory or corporate portal without friend connections, if it requires complex conditions based on groups, language, payments, interests, or age, or if the platform already provides a more current, documented welcome recommendation system. Do not use it to expand a social network without users' knowledge: the automatic connection should be understandable to the user and must not conflict with the privacy settings of the selected component.

Practical rule: first define the human reason for the connection, then configure the technical rule. If the reason sounds like "it is more convenient for the administrator" but makes no sense to a newcomer, choose a welcome message, group, or profile guidance instead.

What to Check Before Installation: Joomla, the Social Component, and Clear Responsibilities

The main dependency for First Automatic Friends is not the site template or a module position, but the social component that stores friend relationships. Product descriptions name Community Builder, JomSocial, and EasySocial. Joomla itself creates a user account, but it does not know how a particular third-party extension handles friendships, requests, and confirmations. Installing the archive without a working social layer already in place will not produce a useful outcome.

Testing is especially important for older solutions. Public product listings may describe a historical release, while current compatibility with your installed Joomla branch, PHP version, and specific version of Community Builder, JomSocial, or EasySocial must be confirmed on a copy of the site. This guide intentionally does not promise compatibility with every modern installation. If the extension will not install in a test environment, does not appear among user plugins, or triggers an error after registration, do not continue testing it on the live site.

Minimum Test Environment

• A site copy or separate test domain using the same Joomla version, PHP version, and active template as the production project.
• One working social component listed in the product description, with profile creation and friend connections already verified manually.
• Three test accounts: a new user, an official profile, and a neutral regular member used to confirm that no unnecessary connection is created.
• Email or an event log, if the selected component sends notifications about requests. This helps distinguish a connection-creation failure from a notification-delivery failure.
• A backup before installation and a clear way to disable the plugin if the rule behaves differently than intended.

Also check how registration works on the site. It may occur through a public form, administrator-created users, or imports. A third-party product description indicates that it handles both public and administrative registrations, but this must be confirmed in your own setup. Imports from another component, LDAP synchronization, user creation through an API, or a migration script may bypass the normal registration event. Do not assume those paths are handled without a separate test.

Separate Sign-In Rights from Friendship Rights

Joomla registration, access to content, and a friend connection are separate layers. A user may receive an account successfully but not see the expected connection because of privacy settings or because the social component has not created a profile yet. Conversely, creating a connection must not automatically unlock restricted content, grant editor permissions, or add someone to internal groups. Review ACL, user groups, and visibility rules separately before installation. Automatic friendship must not be used as an access-provisioning mechanism.

Installation and Initial Testing Without Affecting Live Registration

First Automatic Friends should be installed like a standard Joomla extension, but the rule should not immediately be enabled on a live site. A safe sequence has four independent stages: save a backup, install the package on a test copy, find and enable the user plugin, then perform exactly one test registration. This order matters because the issue can occur at any point. If the archive does not unpack, it is an installation issue. If the plugin does not appear in the list, the package may be incompatible. If a new profile appears but no friendship exists, investigate the configuration and the interaction with the social component.

In the current Joomla administrator interface, the path usually begins in the extension installation section. Screen names differ slightly between CMS branches, so use the system installation section rather than relying on old screenshots. Upload the extension archive you have obtained through the standard uploader and wait for the result message. Do not manually unpack the package into core directories or replace files in existing components: that makes rollback harder and troubleshooting nearly impossible.

Installation Sequence

1. On the test copy, make sure you can sign in to the administrator panel and that the backup is available for restoration.
2. Open Joomla's standard installation page and select the option to upload an extension package.
3. Send the archive to the installer, wait for the operation to finish, and save the exact message if Joomla reports a warning.
4. Go to plugin management and find the First Automatic Friends entry or a name containing FirstFriend. Do not enable a similarly named system plugin at random.
5. Open the identified plugin's details, review the available options, and only then enable it for testing.
6. Create one new test account using the same registration path real visitors use.

In some older packages, the folder name or internal plugin name differs from the marketing name. For that reason, do not search only for the exact phrase from the product listing. However, do not infer its purpose from one similar-looking name. Open its description and confirm that it is a user plugin intended to create initial friend connections. If no such entry exists, stop there: uploading the same archive again rarely resolves a compatibility issue.

What Counts as a Successful Initial Test

Success is not simply a green installer message. After a test registration, every expected sign should be present: Joomla creates the user, the social component creates that user's profile, the selected official account exists, and the Friends or Requests area shows exactly the connection defined by the rule. If request mode is used, check both sides: what the newcomer sees and what the selected profile sees. If confirmed friendship mode is used, check the friends list from both sides, not just the administrative notification.

Also make sure the test registration did not receive unnecessary relationships. That is why the third neutral account is needed. It must not appear among the new user's friends if you configured a single official profile. This check identifies an accidental "all users" mode selection faster than inspecting one expected contact.

Quick takeaway: after the initial test, you should know not only that the plugin is enabled, but also where the social component displays the created connection, who initiates it, and whether the outcome requires confirmation.

Configuring First Automatic Friends: Choose Recipients First, Then the Relationship Type

Detailed configuration begins not with checkboxes, but with the list of target accounts. Based on the available product description, the extension can work with one or several users, as well as all users in the community. That choice determines the meaning of the entire automation. For most sites, the best starting configuration is one official account. It is easy to test, does not overwhelm members, and does not require explaining dozens of new connections immediately after registration.

Create or select the official account before adding it to the rule. The profile should have a stable name, avatar, purpose description, and a designated owner within the team. Do not use an administrator's personal profile if newcomers will read it: when staff changes, you will have to sort out accumulated connections and private messages. An official profile is easier to hand over, manage, and keep separate from regular activity.

Choosing Recipients: One, Several, or Everyone

After choosing the accounts, decide what "adding friends" means in your component. First Automatic Friends descriptions distinguish two behaviors: creating confirmed friend relationships and sending requests. Do not substitute one for the other in site copy. A request preserves a confirmation action for the user or second account, while an already created friendship displays the connection immediately. Which option is available depends on the Community Builder, JomSocial, or EasySocial integration and your version's parameters. Verify the actual behavior through a test registration.

Settings to Check First

When you open the plugin settings, begin with the social-system selection and target-user settings, if they are available. Confirm that the selected component is the one that actually manages profiles on the site. Having multiple social extensions left over after a migration can cause the plugin to use the wrong data set. Then check the relationship mode: confirmed connection or request. After each change, save the settings and run a new registration with a separate test user. An old test account cannot prove the behavior because the rule normally runs only once, at the moment of creation.

For JomSocial, the product description states that a custom message field is available when sending a request. Keep it brief and useful: explain that this is the community's official contact and where to ask questions. Do not include promises, personal data, or long instructions. The message should make sense outside the registration page context. If your version does not include the field, do not imitate it by editing files: configure the component's neutral default behavior and add a welcome message on the public site instead.

A Setting You Should Not Enable "Just in Case"

Mass mode for all existing members is not a harmless demonstration. Before enabling it, assess the number of users and the social consequences. With every new registration, the system may create many relationships or requests, affecting notifications, friend lists, and privacy expectations. Measure the behavior on a site copy with several test accounts and review the state after deleting the test user. If you cannot explain how to correct an accidental mass creation of relationships, leave the mode disabled.

Do not use the plugin as a way to send a message to every newcomer, either. Its task is to manage a relationship in the social model. Welcome emails, community rules, and notifications should remain in the mechanisms intended for them. Keeping these roles separate reduces the risk that changing one automation unexpectedly affects another.

If the test does not change after saving the settings, do not switch several values in a row. Revert the most recent change, clear only the test relationships through the social component interface, create a new test user, and repeat one step. This disciplined approach provides evidence of the cause instead of a lucky result.

How Registration Becomes an Initial Friend Connection

The most useful way to understand First Automatic Friends is not through its settings screen, but through the chain of actions that occurs after registration. In simplified form, it works like this: a visitor creates a Joomla account, the selected social component creates or finds their profile, the user plugin receives the registration event, matches it against the configured rule, and instructs the component to create a friendship or request. The social component then displays the new state in the profile, friends list, or notifications. Each step has its own possible failure point, which makes this model far more useful than trying to "reinstall everything."

First Automatic Friends should not independently decide who counts as a friend. That information belongs to Community Builder, JomSocial, or EasySocial. Joomla handles the basic account and triggers user lifecycle events. The plugin links those two systems according to a predefined rule. A successful installation therefore does not mean that the social component is ready to accept the connection: the target user may have no profile, friendship may be disabled, or a different confirmation mode may apply.

Rule Inputs

Each new member requires at least four clearly defined items: the new Joomla user, the selected social component, the list of target profiles, and the relationship type. If any one of these is undefined, a correct output is impossible. For example, the recipient list may exist, but the official account may have been deleted from the social system. Joomla can then create the user without an error, while the friendship step produces no outcome or an error record. That is not a reason to create a second official user with a similar name - first restore the unambiguous link between the Joomla account and the component profile.

When working with multiple recipients, it is especially important to keep the input list current. Assign one administrator to maintain it. When a mentor leaves the project, remove that person from the rule first, then check new registrations, and only then close their access. Otherwise, new users will continue to receive a connection with a profile that no one manages anymore.

Processing: A Rule, Not a Recommendation

The extension's behavior is deterministic. A new account does not receive the "best" friend and no choice is made based on activity. The plugin applies the set listed in its settings. This is an advantage for a managed community: the outcome can be tested with a new user and explained in the rules. It is also a limitation. If you need to recommend people by language, group, interests, or region, you will need another tool or custom development using documented extension points in the selected social component.

Do not attempt to solve complex segmentation by creating several conflicting rules and silently changing Joomla groups. There is no confirmed evidence that First Automatic Friends can filter recipients by user groups, profile fields, or registration conditions. Without that confirmation, it is better to treat it as a general onboarding rule. For a segmented workflow, use built-in social-platform features, separate groups, or manual moderation.

Output: Connection, Request, and Observable Proof

The output is not an abstract indication that "the plugin ran," but a specific change in the social model. If a request is selected, the proof is found in incoming or outgoing requests, not necessarily in the friends list. If confirmed friendship mode is selected, the proof should be visible to both parties. Community Builder, JomSocial, and EasySocial use different screen names and display details, so document your own verification path in plain language for the team: "Open the new test user's profile, go to connections, and make sure the Community Team account is visible."

An email or interface notification is an additional indicator, not the primary one. It can be suppressed by email settings, a queue, or user preferences. Check the friendship data and status in the social component first, then investigate notification delivery. This separation noticeably speeds up troubleshooting.

Social Components and One Rule with Different Effects

First Automatic Friends listings mention Community Builder, JomSocial, and EasySocial. For an administrator, this does not mean all three components should be enabled at once as a precaution. A site should have one clearly defined source of profiles and friend relationships for this use case. If the database still contains remnants of an earlier migration, similarly named accounts and parallel profiles create ambiguity rather than convenience: you may be checking friendships in one component while the plugin tries to use another.

Community Builder

If the community is built on Community Builder, first walk through registration and profile opening manually. Confirm that social connections are enabled and available to a registered user. Then add a test connection manually through the component interface. This establishes a baseline: if a manual friendship cannot be saved or displayed, First Automatic Friends cannot repair the underlying model. Only then configure the automatic rule with a single official account.

Your test should answer two questions: is the profile created together with the Joomla user, and where does the component display the new connection? Do not use Joomla's user management screen as proof of friendship. It confirms only the base user account. The social layer exists in Community Builder's data and views.

JomSocial

For JomSocial, it is especially important to distinguish a request from a confirmed connection. The First Automatic Friends description mentions a custom request message, so it makes sense to verify both the request record itself and the text the recipient sees. The official message should be short: "This is the official community team profile. You can ask questions about getting started here." If public rules require consent, choose a workflow that does not feel like hidden pressure.

After testing, open both profiles and make sure the request is not duplicated. Re-registering with the same address or copying a test database can create unusual states, so every test should use a new test account. If a request is sent but not displayed, check JomSocial friendship and visibility settings before changing plugin parameters.

EasySocial

When using EasySocial, verify when the profile is created and how the component interprets relationships between users. The official application listing on StackIdeas describes automatically adding a new user to one, several, or all users, along with request or confirmation modes. This confirms the intended purpose, but it does not replace a compatibility test with your installed version. Create a profile manually first, then verify the automated outcome.

The advantage of this approach is that you do not rely on the appearance of old administrator-panel screenshots. What matters is the observable outcome: the new person is created, the profile is found, the chosen official contact appears in the correct state, and the neutral account remains unaffected. If this chain is confirmed, the team can document its local process without inventing menu items.

Why Full Compatibility Cannot Be Promised

First Automatic Friends was published as an older extension, while Joomla and social components evolve independently. Even when a component name matches, internal models, registration events, and PHP requirements change. The accurate statement for a site owner is therefore: "the extension is listed for this social platform, and compatibility is tested on a copy of the specific site." Do not install it directly on a production project with many registrations, and do not disable your backup sign-in method.

Post-configuration verification: a test passes only when you can see the expected connection state in the same component that manages community profiles and can reproduce it with another new account.

Practical Example: A Team Profile Welcomes a New Member

Consider a workflow that suits most small communities and does not depend on unconfirmed complex conditions. The site has an official "Community Team" profile. It publishes rules, answers newcomer questions, and is not used for an employee's personal activity. The goal is for a newly registered member to see this profile as their first connection or receive a clear request from it. We are not connecting the newcomer with all users, changing their Joomla permissions, or trying to grant access to restricted sections through friendship.

This setup is useful because it is easy to test. There is one source of the rule, one expected outcome, and one control account that must not become connected to the newcomer. If this minimum configuration works consistently, you can later consider adding a second coordinator. If duplicates, permission errors, or unusual displays appear at the first step, it is too early to scale the automation.

Goal and Preparation

Create three accounts on a copy of the site. The first is the official team profile, which already displays correctly in the selected social component. The second is a neutral user called "No Connection Check"; it serves as an indicator that the rule has not become a mass operation. Do not create the third account in advance: it will be the new user registered during the test. Prepare a separate email address or valid test address that does not match an existing account.

Before enabling the plugin, make one manual observation: open the team profile and make sure it is available to the groups allowed to register. If the profile is hidden, disabled, or removed from the social layer, First Automatic Friends cannot turn it into a clear first contact. Then check what an incoming request and an already confirmed friendship look like in the selected component. Do not rely on memory: perform one manual test that you can later remove through the interface.

Configuring the Rule on a Site Copy

1. Make sure the First Automatic Friends plugin is installed, visible in the plugin manager, and disabled before testing.
2. In its parameters, select the social component that actually manages the site's profiles, if that choice is available.
3. Specify only the "Community Team" profile as the target user. Do not add the neutral test account or select all users.
4. Choose the available relationship mode. If an explicit action by a participant is required, prefer a request. If your private-community rules clearly provide for an established initial connection, test confirmed friendship mode.
5. For JomSocial, if a message field is available, write one calm message without calls to action or personal promises.
6. Save the parameters, enable the plugin, and do not change other settings until the first registration is complete.

At this stage, it is useful to write the expected outcome in one sentence: "After registration, Test Newcomer receives a request from Community Team, and the neutral user is unaffected." This statement serves as the success criterion. It protects against the common mistake of an administrator seeing any notification and considering the task complete even though the wrong connection was created or too many connections were created.

Test Registration and a Two-Sided Review

Open the registration form in a separate browser session or use another browser profile. This avoids influence from your current administrator session. Register a new user exactly as visitors do: through the public form, with the same required fields and confirmation if it is enabled. Do not create the user through the administrator panel to test the public path - that is a different workflow, even if the product description says both registration types are handled.

After registration is complete, do not stop at the success page. Sign in as the new user, open the selected social component's connections area, and compare the state with what you expected. Then sign out and sign in as the team profile. If a request is used, check where it appears, which party is expected to act, and whether the specified message is shown. If a confirmed connection is used, verify mutual presence in the friends list. Finally, sign in as the neutral account and make sure it has not received a new relationship.

What to Record in the Team's Operating Instructions

After a successful test, there is no need to keep lengthy technical logs in a user-facing note. It is enough to record five things: who owns the team profile, the selected component, the target account, the result type, and the verification path. For example: "The plugin creates a request to the Community Team profile; check it in the new user's requests area and in the Team profile; only the community manager may change the recipient list." This record helps when staff changes and prevents accidental edits.

How to Verify the Outcome After Launch Without Confusing Friendship with a Notification

After configuration, use a short, repeatable test that the team can perform after updating Joomla, the social platform, or the plugin itself. It does not need to be complex, but it must cover the entire chain: user, profile, connection, and unwanted side effects. A registration email, a successful sign-in screen, and the absence of a PHP error do not by themselves prove that First Automatic Friends took the required action.

Test Case Matrix

Perform this test on a site copy after updates. On the live site, it is enough to periodically observe the first real registrations if doing so does not violate privacy. Do not inspect users' private conversations to prove that the plugin works. A designated test account and events the team may access under community rules are sufficient.

Safe Rollback

If the outcome does not match the rule, first disable the plugin through the plugin manager. This stops new automatic connections from being created and does not remove existing relationships without your decision. Then remove only test relationships through the social component's standard interface, restore a backup in the test environment if necessary, and identify the cause. Do not manually delete database records: friendship data may be connected to notifications, profiles, and internal component counters.

Readiness indicator: the rule can be considered suitable for the live site when two consecutive new test users receive the same expected outcome and non-target accounts receive no unintended connections.

Privacy, Notifications, and Load: What Automation Changes After Registration

Automatic friendship affects more than an attractive onboarding experience. It creates a social expectation: a newcomer sees that a connection appeared without a manual search, while the selected account may see a request or a new friend. Before launching it on a live site, agree on three rules: who may be a recipient, what the created connection means, and who handles responses to it. Enabling the technology without these agreements turns useful automation into a source of misunderstandings.

Start with a public explanation. A single transparent sentence in registration rules or a short welcome message is enough: "After registration, you will see the official team profile, where you can get help with the community." There is no need to list internal settings or promise a personal response at any time. The goal is to make the first connection predictable. If you use a request instead of an established friendship, explain that it can be accepted or left unanswered according to the selected social platform's behavior.

Why an Official Profile Is Better Than a Personal Account

An administrator's personal profile may seem like a quick solution, but it combines support, private communication, and technical site ownership. During vacation, team changes, or access conflicts, new members will keep receiving a connection with someone who no longer manages the community. An official account separates the function from the individual. It can maintain a clear description, a consistent response style, backup ownership, and an understandable handoff process.

Check the official profile's visibility through the eyes of a regular registered user. If it is hidden from some groups, an automatic friendship may be created in the data but fail to provide a clear public-site outcome. If the profile is visible too broadly, it may be better to change the component's visibility settings rather than compensate with new First Automatic Friends rules. The plugin creates a relationship, but it does not design your privacy policy for you.

Notifications Are Not the Operation Itself

A connection and a notification should be diagnosed separately. Suppose a new user sees a request but receives no email. In that case, First Automatic Friends and the social component may have created the record correctly, while the issue lies in mail configuration, a queue, or user preferences. The reverse is also possible: an email template is sent, but the connection is unavailable because of the friendship state. Changing plugin parameters in response to an email issue only makes the situation harder to understand.

For the official profile, it is useful to select one handling channel. This might be a periodic review of incoming requests or guidance through the rules page, but not an automated promise of immediate personal help. If the component has separate notification settings, test them after connection creation has been proven. In the team's change log, record only facts: the date of the internal check, selected result type, number of target accounts, and responsible person. Do not publish test users' personal data.

Assess the Scale Before Using "All Users" Mode

Connecting with all users may look like a way to make a network feel active quickly, but it creates relationships between people who do not know one another. In a small private site, that can be normal. On a platform with a steady stream of newcomers, the number of connections, requests, and notifications grows quickly. Along with the load on component data, there are social consequences: users see expanded contact lists, receive unexpected requests, and stop treating friendship as a meaningful action.

If the team is still considering this mode, start with a written decision rather than activation. Define the maximum community size, a rule for deleting or deactivating old accounts, the response to refusals, and how members will be informed. On a site copy, create several users, count the outcome of one new registration, and make sure requests do not create cycles or duplicates. If the component offers additional friendship settings, compare them with this decision. At the first sign of uncertainty, return to one official profile.

Using Joomla's Built-In Mechanisms Without Inventing Integrations

First Automatic Friends can be used alongside standard Joomla registration and the selected social component's settings, but this does not mean it has official integrations with every extension on the site. A practical setup is built around roles. Joomla creates the account and applies access groups. The social component creates the profile, visibility rules, and friendships. First Automatic Friends creates the initial relationship. A welcome page or email explains the next step. When responsibilities are separated, each part can be tested and rolled back independently.

A Working "Registration - Profile - Guidance" Setup

First, configure standard Joomla registration so the user enters the correct base group. Then confirm that the selected social component creates a profile and displays it on the public site. After that, First Automatic Friends adds only the selected official contact. Finally, use the welcome message or visible official-profile description to provide the next safe step: review the rules, open the help section, or introduce yourself in an open group.

This is not a developer-declared "integration" with a specific email service, template, or newsletter component. It is a practical setup based on separating the normal responsibilities of Joomla and social extensions. Its advantage is reversibility. If automatic friendship is not suitable, you disable only the plugin while registration, profiles, and site rules continue to work.

Testing Order After Access Changes

Changes to Joomla groups or profile privacy often happen outside the community team, so they can quietly break the first contact. After any ACL edit or visibility restriction, repeat the minimum test: register a new user with regular permissions, open the team profile, and check the created relationship. Do not test as a Super User, because those permissions hide the real issue. If the connection exists but the profile is unavailable, correct access boundaries in the component or Joomla groups, not recipient parameters in the plugin.

Caching and Stale Page State

Caching can create the impression that a connection did not appear if a profile or friends list displays a stored page. First refresh the page in a new session and check the data in the social component itself. If the state appears after clearing permitted cache in the test environment, add that fact to your local instructions: cache affects display, but not necessarily relationship creation. Do not disable system caching permanently because of one unclear test. Isolate the cause and restore reasonable performance settings.

Safe Improvements Around the Plugin: What You Can Do Without Editing Its Files

First Automatic Friends has no confirmed public set of hooks or template parameters for custom development, so inserting PHP code, accessing internal tables, or editing plugin files would be risky. A durable improvement path sits alongside the extension: make the official profile useful, configure clear request text where supported, and use Joomla's built-in language overrides for the site's general terminology.

For example, if the word "friend" does not suit a professional community, do not change the plugin code. First check whether visible strings can be changed through Joomla language overrides or social component settings. Work on a site copy: find the exact language string, create an override for the current language, clear only the necessary cache, and check the public outcome as a regular user. If the result is unwanted, disable the override you created. This is a reversible configuration change that does not interfere with extension updates.

Another safe practice is to fill out the official profile. Add brief rules, response times, and a link to the site's help section if one exists. The automatic connection then leads not to an empty account, but to a genuine point of guidance. This work requires no changes to the CMS, plugin, or database and remains useful even if you later decide to disable First Automatic Friends.

Important boundary: if the desired behavior requires changing extension files, creating SQL queries against friendship tables, or imitating an internal registration event, stop and look for a documented mechanism in the social platform. For an older plugin, the cost of that customization is usually greater than its benefit.

Troubleshooting First Automatic Friends: Find the Break in the Chain Instead of Changing Everything at Once

Almost all issues with automatic friend creation can be divided into five areas: package installation, plugin activation, Joomla user creation, social-component profile creation, and creation of the connection itself. This model is more useful than a list of random suggestions. It lets you check one fact, take one reversible action, and immediately see whether you moved closer to the expected outcome. Before troubleshooting, disable the rule on the live site if there is a risk of creating incorrect relationships for real users, and repeat experiments on a site copy.

The Plugin Will Not Install or Does Not Appear Among User Extensions

Symptom: the Joomla installer reports an error, finishes with a warning, or no First Automatic Friends entry or similarly named FirstFriend plugin appears after installation. Likely cause: the package is intended for a different Joomla or PHP branch, the archive is corrupted, or it uses an outdated extension structure. This is especially likely for a historical product whose compatibility has not been confirmed for every modern configuration.

What to check: repeat installation only on a test copy, save the exact system message, and compare it with your installed Joomla and PHP versions. Confirm that you are uploading the original package rather than an unpacked folder or an archive inside another archive. How to fix it: do not copy files manually or suppress the error by changing directory permissions at random. Find a compatible build or stop using the plugin in this configuration. When to roll back: immediately, if installation changes the site state or causes administrator-panel errors.

A New User Is Created, but No Friend Connection Appears

Symptom: registration completes, the Joomla account exists, but there is no request and no new friend in the selected social component. Possible cause: the plugin is disabled, the wrong social component is selected, the new user does not yet receive a profile, or the target account is not linked to an active component profile. What to check: start with the plugin state, then manually create a friendship in the same component and confirm that it works at all for two test users.

How to fix it: enable only the confirmed plugin, select one target profile, and register a new test user. If manual friendship does not work, fix the social component before addressing the plugin. If the new user's profile appears with a delay, first investigate the profile-creation behavior of the selected platform. When to roll back: if any change causes unexpected registration errors, disable First Automatic Friends and return to the original model.

A Request Is Created When a Confirmed Friendship Was Expected, or Vice Versa

Symptom: the new member sees an outgoing request instead of a friend, or a connection appears without a confirmation step. Likely cause: a different relationship mode is selected in settings, while expectations are based on another social component's behavior. What to check: define the expected outcome before the next test and review the state from both sides. Do not confuse a request notification with confirmed friendship.

How to fix it: in the test environment, change only the relationship-type parameter, save it, and register an entirely new user. If your version does not offer the required option, do not imitate it by manually editing the database. Choose the available model, explain it in the community rules, or consider another tool. When to roll back: if the selected mode conflicts with the site's consent or privacy policy.

New Members Receive Too Many Friends or Requests

Symptom: instead of one team account, a newcomer sees many users, or numerous members receive new notifications. Possible cause: all-users mode is enabled, extra accounts were included in the list, or several rules are running at the same time. What to check: immediately stop new registrations in the test, disable the plugin, and record the number of affected test profiles. Then open the settings and compare the actual recipient list with the written rule.

How to fix it: keep one official account, remove unnecessary test connections through the social component interface, and repeat the test with one new user. On the live site, first assess relationships that were already created and agree on proper removal under the community policy. When to roll back: without exception, if you cannot predict the number of relationships after one registration.

The Team Profile Is Not Visible to a New Member

Symptom: a test may show a relationship record, but a regular user cannot open the official profile or does not understand who it is. Possible cause: privacy settings, Joomla access groups, profile status, or restrictions in the social component itself. What to check: sign in as a regular new account, not as a Super User, and open the profile through the normal user path.

How to fix it: configure the official profile's visibility and access to its base page in the component that manages profiles. Do not change the new user's permissions for the sake of one friend connection. When to roll back: if making the profile available requires granting a newcomer permissions unrelated to communication.

The Connection Appears Only After Clearing Cache or Is Not Visible Immediately

Symptom: after registration, the outcome is absent on the first page but appears in a new session or after clearing permitted cache. Possible cause: a stored friends-list page, client-side cache, or a delayed interface update in the component. What to check: first open the profile in a clean session, then check the friendship record through the standard interface. How to fix it: document the correct verification path and configure cache exclusions only when they are confirmed for your component. When to roll back: if achieving the visible effect requires disabling cache for the entire site.

Administrator-Created Registration Behaves Differently from Public Registration

Symptom: a user created through the administrator panel receives a different connection or no connection, although the public form works. Possible cause: different account-creation paths, plugin execution order, or the absence of an automatically created profile. The product description mentions handling public and administrative registration, but this must be confirmed in your actual setup. What to check: run two separate tests and compare the outcomes without combining them into one.

How to fix it: if the business process requires a manager to create accounts, document a separate operating procedure for that path. If there is no reliably consistent outcome, check the profile after administrative creation and add the connection manually through a transparent procedure. When to roll back: if automation makes the administrative process less predictable.

Core troubleshooting principle: one new test registration - one verifiable workflow. Do not change friendship mode, recipient lists, ACL, and cache at the same time, or you lose the ability to identify the actual cause.

When First Automatic Friends Is a Good Choice

The extension makes sense when a Joomla site already uses Community Builder, JomSocial, or EasySocial and the team needs a simple, understandable first contact for a new member. The most reliable setup is one official profile, a transparent explanation of its role, testing on a site copy, and repeatable checks after updates. This keeps automation as a supporting function rather than a hidden attempt to control users' social relationships.

Before going live, check four conditions once more: the social component can create profiles and friendships manually, the plugin installs without errors on your Joomla copy, a new test user receives exactly the expected connection type, and the non-target account remains unchanged. If even one condition is not met, it is better to leave the plugin disabled and use the familiar manual process until compatibility is clarified.

Once the rule is confirmed and the team understands its effects, you can download the installation package, install the archive in the test environment first, and save local verification instructions. This order gives users a clear first contact and gives the administrator a way to identify and safely stop incorrect automation quickly.