Composr Related Issues

Question What Composr is not – Composr?
Answer

Designed to meet fads

We don't specifically design our system just to match the passing trends like 'social media', 'web 2.0', 'cloud computing', 'SaaS', and 'platform'. Don't get us wrong – many of these are great ideas and Composr does include most of it. But we don't toss these phrases around simply because they're fashionable – we use them when appropriate and always develop to meet rock-solid established needs. The truth is many of these trends aren't new at all – there's a cycle of technology, and often Composr can meet trends before they come back again. It's just we might not call it the same thing!

Sadly, much of Open Source software is presented in a disorganised way. With Composr, we intentionally present it as a very organised, “easy out of the box” solution. Our approach prevents you having to kludge together a solution from a disparate mess of third party contributions, and trawl a whole scattered community of documentation for help.

Composr is Open Source – in other words, free. Users can customise it how they want, using and employ whoever they want to do it. Competing systems (true competitors – not basic CMS's) typically cost over $10,000 – which you only find out after making a phone call to a sales representative.

We don't limit you to what you are allowed to do with Composr, and you can even fork the software (distribute your own versions). We give you the code and you can do what you want with it. Unlike some other CMS we don't charge for de-branding: in fact we have made one simple inbuilt option to de-brand your copy of Composr.

We also strongly believe in creating an open marketplace where people can use our software freely. We do offer our own professional services but we hope users will choose our services based on quality and our relationship with the software – not by vendor lock-in or monopoly.

This may be the latest buzzword, but it's a buzz with a sour taste. Many SaaS services run on remote servers and you can't make your own modifications. This sucks as much as closed-source software. It's very easy to get a hosting account, or cloud hosting, and install Composr (many hosts can auto-install it for you) – with all the advantages of strict SaaS but without any loss of control. If you're creating a novel website, you need the option to fully control its code!

Composr is best for building whole websites, rather than “mash-ups”. We intentionally try and incorporate the features you will need inside the software itself.

When we design Composr we try to be neutral and not directly incorporate features for integrating with specific third-party services, such as Adsense or Amazon affiliates. Instead we provide the flexibility for users to add in this kind of integration as required.
This way we aren't constantly catching up with a changing market, or making commercial decisions or implied recommendations on behalf of other people.

Composr doesn't have hundreds of addons to dig through but that is by design. The majority of features you'd ever need are built in, which is our equivalent to the hundreds of addons you might want to install for other software. Our inbuilt features are wonderfully integrated and organised and can be uninstalled if they aren't wanted (the Setup Wizard will recommend to you what you probably do/don't want).

It is important that Composr is flexible, but if we did it by adding 1000s of options for controlling every part of it, it could never work:

  1. We'd be second-guessing users, so would always be missing things, however many options we added.
  2. The administration would be so complex that it would be unusable.

We solve this problem in three ways:

  1. We remove any unneeded complexity. We pick one good way of doing things that works for most users rather than giving choices that very few would care about.
  2. We allow for enormous flexibility by implementing everything on top of a highly customisable framework. For example, you can override any template to change layout, using our Tempcode language to great effect.
  3. We are an Open Source non-compiled product, meaning programmers can make changes to the underlying PHP code easily. Further to this, we have a sophisticated override system that lets you change all parts of the system in a pin-pointed way.

Composr does not have a segregated admin section in the common sense. Composr gives you complete permissions & privileges control, allowing you to control exactly what you want areas you wish to give users and staff. The divisions are not hard-coded how a third party developer thinks it should be.

We don't have advanced inbuilt analytics and we don't try and replace image editing software. The reason is simple – there are already great options for these out there, and there is no disadvantage to just using those options. We really believe very strongly in the importance of integration in order to create a consistent website and brand experience, and to make administration saner, but we don't need to reinvent the wheel when these kinds of advantages don't apply. So enjoy Google Analytics and Paint.net, and we'll continue to invest our time in the great innovative features you love.

We don't give the webmaster a drag and drop feature to place blocks because you need more control. For example, you might want to make a block only show to certain groups, have subtle layout changes for different tablet sizes, or add some randomisation logic to conduct split testing. We've seen many CMSs that provide drag and drop and end up really limiting what you could achieve and we know from experience it would not work for the sites people want.
Instead of drag and drop we have an 'Add block' button, which adds the code for the block to your content. You can then preview the block via a tooltip. It's just as easy, but far more powerful!

Composr does not export content to static HTML files for you to upload to a conventional web server. While this approach might result in very fast websites, it is extremely limiting: social applications need dynamism and a deal of interaction which static sites can not offer. This said, there is a Composr option to cache full page content for guest users, and this provides incredibly high performance. We do actually have a static export addon too, but we don't bundle it and it naturally can't support most of Composr's dynamic features.

There are some features we are unlikely to build into Composr, if we feel they are too obscure, unbalancing, would be costly to maintain for little benefit, or would lead to 'bloat'. For example, we are unlikely to release gaming addons in the Composr distribution.

We also consciously avoid certain kinds of feature if they don't fit into the Composr design or philosophy. For example, 'form builders' are very popular and common in other software, but we have not implemented them because Composr has a different but more flexible alternative – catalogues (for which notification e-mails can be sent and data saved and searched).

Composr is commercially-backed, so there is always someone to turn to if you need help.


 
Question     Newsletter Confirmations         Is there a way to disable "confirmation" of newsletter signups? I still want to send an email, perhaps welcoming them or confirming they've been added, but without the requirement to "click-to-confirm"?
Answer
Is there a way to disable "confirmation" of newsletter signups? I still want to send an email, perhaps welcoming them or confirming they've been added, but without the requirement to "click-to-confirm".

Yes and no.

If you use the 'path' parameter on the main_newsletter_signup block (points to a Comcode-containing text file which will be sent out when people signup with that block) no confirm will happen.
So that's what you want.
You cannot do it for signups directly through the module.
Make sure the path you use is relative to the base directory (install directory).
 
If a member signs up through the block, I'm able to customize the confirmation email by uploading and referencing a file to the block's params (if this file doesn't exist or I don't specify one, the default confirmation email is sent)

Yes (same thing I mentioned above).
 
If they signup through the :newsletter module/page, they are sent a similar confirmation email but with a different layout. This email contains additional formatting. Unlike the confirmation email sent by the block (which is basic, no comcode), this confirmation email is surrounded in what looks like a box tag.

I'm not sure why there'd be a difference from analysing the code just now. In both cases it should be sending the NEWSLETTER_SIGNUP_TEXT language string, which contains Comcode for the e-mail.
The default mail template does have a box around stuff, wrapping the e-mail content.
 
So my question here is - can I customize the email that the :newsletter module sends (similar to how you can with the newsletter block by creating a custom file)?

Yes, change NEWSLETTER_SIGNUP_TEXT.
 
Also, is this the best way to customize these emails? i.e. as opposed to modifying a mail template?

Most e-mails come out of language strings, and it's functionally equivalent to editing a template.
 
When 'sending fresh newsletter issue', there is a setting option at the bottom that asks which template the email should use. Even though there is only one to choose from (the 'MAIL' template), where do I find this template to modify it? I've searched all the templates relevant to the newsletter module, and none seem to really define a layout for the actual email the system sends out.

You need to manually create a template that matches the filename pattern MAIL*.tpl.
 
If I put 0 here, does it send the email instantly?

If CRON is set up, it's the next run of CRON.
 
Possible bug #1: There may be an issue isolated to my specific installation, but whenever I create a welcome email, choosing 'Edit welcome email' on the previous page yields no results; as if it's not saving to the database.

I can see an issue with multi-site-networks. It's saving onto site-db and reading from forum-db. It's meant to do all welcome emails from site-db, as they are site-specific (even though it is a part of Conversr, which is a little confusing).

Here's a patch….
 

Code (Diff)

diff –git a/sources/crud_module.php b/sources/crud_module.php
index 084d32427..55e854661 100644
— a/sources/crud_module.php
+++ b/sources/crud_module.php
@@ -1118,7 +1118,7 @@ abstract class Standard_crud_module
         }
         $table_raw = (is_null($this->table) ? $this->module_type : $this->table);
         $table = $table_raw . ' r';
-        $db = ((substr($table, 0, 2) == 'f_') && (!$force_site_db) && (get_forum_type() != 'none')) ? $GLOBALS['FORUM_DB'] : $GLOBALS['SITE_DB'];
+        $db = ((substr($table, 0, 2) == 'f_') && ($table != 'f_welcome_emails r') && (!$force_site_db) && (get_forum_type() != 'none')) ? $GLOBALS['FORUM_DB'] : $GLOBALS['SITE_DB'];
         if (($orderer_is_multi_lang) && (preg_replace('# (ASC|DESC)$#', '', $orderer) == $select_field)) {
             $_orderer = $GLOBALS['SITE_DB']->translate_field_ref(preg_replace('# (ASC|DESC)$#', '', $orderer));
             if (substr($orderer, -5) == ' DESC') {
 

Let me know if you need some help there like an actual new file.
 
Possible bug #2: The 'there is a tutorial that covers this feature' link directs me to a tutorial on the member system. Its irrelevant in regards to welcome emails, hence why I'm inquiring about the 'Send time' option

Ah, yes. It's on tut_adv_members not tut_members. Fixed.
 
Sorry for the long post. Just had a few questions! :)

They were very good questions.

Last edit: by Chris Graham