Below is a list of the most common technical questions that we are asked.
You can modify the UI by using the custom CSS overrides section in the admin. You do not need to buy the source code to customize the user interface. You just need to understand the CSS framework, which is based on Bootstrap, and modify the default ASCX/ASPX pages.
Communifire supports SSO and can be easily integrated within an existing website as a sub-community or a separate sub-domain website. For details on SSO, Single Sign On (SSO) .
Yes, Communifire supports flexible database based localization, for more details refer Localized Content .
Communifire supports an event-driven model, which makes it easy to "hook" onto certain events and plug-in your own custom code. The best way to extend Communifire is to use events hooks as explained here.
Also, you can easily override the default Provider classes that come with Communifire with your own custom versions, without needing to modify core source code. If you feel that the above methodology will not work for major modifications, you can simply add new modules by creating new data tables and adding custom code with Communifire published files setup as a Visual Studio project as shown here.
For source code customers: We recommend that you use Communifire code as reference to add new modules/features, but avoid modifying the code directly so that future upgrades are easy.
Refer this wiki page on Communifire Permissions.
Yes, absolutely. Refer this wiki page for using the Communifire API.
You can easily add custom fields to the user profile section under different profile groups, and you can also create new profile groups, refer this wiki page for details.
Yes, Communifire can easily be run on a web farm. Also, since Communifire doesn't use Session state, you do not need to worry about sticky sessions while running Communifire in a web farm environment.
Please refer this wiki.
Communifire comes with a Caching Provider framework that lets you plug in your own caching system, without the need to modify the source.
By default, Communifire runs on CFDefaultCacheProvider, which uses the.NET Cache object (HttpRuntime.Cache), but we also have a memcached provider implementation to support distributed caching.
You can also create your own custom caching provider and plug it in Communifire.
Yes, Communifire supports Facebook Connect, Twitter and Open ID integration, out-of-the-box. For details, please refer to this wiki page.
This might happen because the Lucene-Status.txt file under /root/assets/ was deleted, the re-indexing will create a duplicate index. To fix this, stop the application pool of your website (via IIS manager), delete all files from /assets/lucene-index/ folder, then delete the /assets/lucene-status.txt file. Then start your application pool, a fresh index will be built.
Communifire can run on SQL Azure with some minor modifications. We don't see any specific issues with SQL Server on Azure. We are not using any of the SQL Azure limitations documented here, like Full-text search, database mirroring etc. SQL Azure databases are currently limited to 150 GB in size. But 150GB is more than sufficient for a stand-alone Communifire installation. Usually a database with around 10-20,000 users with lots of "text" content like articles, blogs etc will be around 10-15GB. The only limitation can be the fact that Communifire makes use of ffmpeg.exe for video conversions. So for Azure's "restricted" environment, some additional configuration and possibly code changes would be required to successfully run an executable on an Azure instance (as mentioned here).
A lot of user data is stored on the file system (known as "media servers" within Communifire). All videos (including converted videos), attachments, files (document management) are stored in the file system. The only data stored in the database is text. Files are not stored in the database. For scaling, the file system can be configured to use a shared server and setting up media servers to point to that location.
Communifire uses a standard .NET implementation of AES-Rijndaehl encryption out-of-the-box. But you can easily plug in a custom implementation by adding your own custom encryption provider instead of the default CFCommunifireEncryptionProvider class. You can do this without needing the source code of Communifire, by simply following the Provider Design Pattern.
We haven't worked on nHibernate extensively, but we see do not see any issues with this approach. Some of our clients have used different ORMs to add custom modules in Communifire without any issues.
SignalR is an abstraction over a connection. It gives you two programming models over that connection (hubs and persistent connections). SignalR has a concept of transports, each transport decides how data is sent/received and how it connects and disconnects.
SignalR has a few built in transports:
SignalR tries to choose the "best" connection supported by server and client (you can also force it to use a specific transport).
If you're asking about how the long polling transport works in particular:
It sends an ajax request to the server that's waiting asynchronously for a signal to respond. When there is a signal or the request times out, it returns from the server and sends another request and the process continues. (I left some details out about how the client it keeps track of what it saw so it doesn't miss messages). This blog post has more info:
You can follows these links here and here.
We are adding a UI based layout editor in the 5.0 release.
Communifire uses a provider model, so it can support other databases, but you will have to rewrite/modify the database layer: create new providers (on the lines of SQL providers) for Oracle like OracleArticleDataProvider, next plug them in CFProviders.config, and modify the stored procs so that they can use Oracle specific optimizations. This whole process is doable without modifying core .NET code, but it might take some time to modify the stored procs as per individual database.
We recommend scaling up, as scaling out SQL Servers/DBs is tricky and not very easy to manage. We use Lucene.NET for searches, taking load off our DBs and helping in scaling out. We use the concept of media servers, storing documents and files, or attachments/media etc on physical servers instead of storing them in a database. The media servers can be configured easily.
No, but we use the concept of media servers, storing documents and files, or attachments/media etc on physical servers instead of storing them in a database.
Though it depends on the hardware where Communifire is hosted, and the fact that Communifire can be easily configured to run on a web farm using a distributed plug-n-play caching system, the system can easily handle 2000 concurrent users on a server with 4GB RAM (assuming database is on the same server).
You can export them to an Excel sheet, and even import the resources from an Excel sheet. Alternatively, you can use the API to modify/add/delete resources programmatically.
CSS/logos/images etc are cached by the browser locally for performance reasons. The branding must have changed but since old branding elements were cached by your browser, they don't show up immediately. You can press "Shift key + Refresh browser button" multiple times to clear the cache, or delete all cached items from your browser to see the new changes. You can also try to see the changes in a different browser where you never opened the site before. It should show your braning changes immediately as it did not cache any older version.
Communifire comes with a user-friendly resource manager in the admin section. You can change any text (edit resources) yourself by going to: cf-admin -> system -> manage-localized-content
Search for the text you want to change, like "articles" and then click the edit icon. Enter the new text in the "Resource Value" text box (make sure you do not change the Resource Key) and click the "update" button. The changes will be visible immediately.
is requesting access to a wiki that you have locked: https://my.axerosolutions.com/spaces/5/communifire-documentation/wiki/view/263/technical-faq