You need to install/enable the spoor extension.

You can use the launchNewWindow extension to get your course to open itself in a new window on iOS, thereby avoiding the iOS/iframe problem.

Hi so I have returned to this and still cant get it to work

on checking the build folder there is the logo as you said however it still wont show up

Navigation.hbs looks like this

navigation. Less looks like this

files i've moddified are

adapt2\src\theme\adapt-contrib-vanilla\less\src\navigation.less

\adapt2\src\core\templates\navigation.hbs

so...what am I doing wrong please :)

Hi Matt

The learning content does contain both video and audio, so therefore it must be using Flash or Silverlight?? However iOS devices aren't able to play Flash or Silverlight, is there an app that can be used to play this content or can this content be recreated so its compatible with iOS devices?

Thanks

Hi,

Welcome to the community. I'll try to answer your questions...

1. As far as I know, Can Studios have the only visual page editor (Disclaimer - I work there) you can see it here https://canstudios.com/adapt-authoring-tool/adapt-support/support-videos/#preview-editor (you are welcome to take a free trial, its automatic sign up so you shouldn't have any issue waiting for a response) though it does not offer complete coverage, it does allow you to create pages, articles, blocks, as well as text, image and mcq content. It is a plug in to the main authoring tool, so you can still build other content into your course in the normal way.

2. The framework does support multiple languages. However the authoring tool does not current support this though I know it is on the road map. In the mean time, there is documentation on how to use this on the Adapt wiki, so you could export your course from the authoring tool and follow this process. 

https://github.com/adaptlearning/adapt_framework/wiki/Course-Localisation

Hope this helps,

Paul.

The data loss issue comes up in failover scenarios with replica sets. Data gets into the master but not yet mirrored to slaves. Then the master goes down. When the master comes back online the data in that instance waiting to be committed sometimes never makes it into the replica set.
It should be noted that MongoDB does provide some tools to help reduce the possibility of data loss on failover.
Write Concern specifies a minimum number of nodes that have to return an acknowledgement of the write. If an operation does not receive the required number of acks in time, it returns with a write concern error. This doesn't mean the write failed, just that it took too long for X number of nodes to acknowledge the write.
Write Concern is useful in that it can help the user keep track of any writes that might not persist in the event of a failover. If you have a write where a majority of nodes have confirmed it is written, it's pretty unlikely that data will be lost during failover.
Read Concern is 3.2 only, and as I understand it only works on WiredTiger storage engines. Using ReadConcern ensures the only data that is read is data that has been confirmed as written on the majority of nodes. So there might be newer data, but the data you are reading exists on the majority of the nodes.
I think, in general, not using write concern properly or not using it at all probably has led to some level of data loss in the past - in some systems, it may not be feasible as speed of writes is more important than acknowledgement of writes, but in that case, some level of data loss should probably be expected.
Ignoring complicated replica setups for a moment, as I couldn't comment on them, although I have had no data loss from the old style master/slave replication.
Most of the documented instances where MongoDB has been losing data has been user error. There are the common causes:
They were running the 32bit version, and ignored the big warning when you start it up saying 'do not run this, you may lose data' (to be fair, if you installed early versions from some repos it wouldn't show that error).
They didn't specify they wanted write acknowledgement (with safe/fsync/w parameters) and it defaults to fire-and-forget, arguably a bad default, but they didn't read the docs either, this itself shouldn't lose data randomly only if there was a power failure or crash.
They did specify write acknowledgement but didn't actually bother checking if the write succeeded. I've seen people doing if(!db.insert(...)) { error }. But if they had read the API docs it's clear that that function call doesn't return false on an error, instead you make a new call to getLastError(). This isn't really any different to running a query against any other database, but not bothering to check if there was an error. Again, user error from not reading documentation.
I've never lost any data in the 5 years I've had an instance in production.

You can sign up for s free trial of our service at https://CanStudios.com/adapt

You will get a dedicated server, with several themes and extensions installed ready to use within a couple of minutes.

We run system updates regularly and will keep the authoring tool up to date for you. We also add new features monthly.

Hope this helps,

Paul