🇪🇹Ethiopia @tsega

tsega → created an issue.

Similar to #9, my issue was related to having a compatible Drush version to my Drupal.

See the Drush install page for details - https://www.drush.org/13.x/install/#drupal-compatibility

This worked for me but it has a typo the `@` sign shouldn't be there:

$settings['reverse_proxy'] = TRUE;
$settings['reverse_proxy_addresses'] = array($_SERVER['REMOTE_ADDR']);

Thanks @nafsinvk, using the steps you provided worked for me.

Thanks @ru.bsv disabling xdebug worked for me. Funny thing is I'm on ddev and xdebug was not enabled.

Patch to stop fatal error.

tsega → created an issue.

@imunklovarian, here is the link to the sample document -https://docs.google.com/spreadsheets/d/1yKAHxUtySDT0bA-eaI-WuawN6WHSGmgh...

I've also updated the README text.

Thanks for brining this to our attention.

Issue is related to a custom patch.

tsega → created an issue.

I was able to follow the instructions, with a minor version change, and successfully install the charts_billboard library.

If you can provide more details of the exact error you faced, I might be able to help.

tsega → created an issue.

Here is the patch to fix this issue:

1. Allows getting back to the activity at which you stopped
2. Turns the activity text into links so users can jump around and access any activity without resetting their progress

After much toiling I found the fix for the issue:

When simpleSAMLphp is setup behind a reverse proxy, similar to what the Openshift setup is like, you need to set the base URL of the application (not simpleSAMLphp admin tool but the actual Drupal site itself) in config/config.php file from simpleSAMLphp.

I add the following and it worked: (note: this piece of code is commented out in the config.php file so you will need to uncomment and set the correct value)

   /*
     * The 'application' configuration array groups a set configuration options
     * relative to an application protected by SimpleSAMLphp.
     */
    'application' => [
        /*
         * The 'baseURL' configuration option allows you to specify a protocol,
         * host and optionally a port that serves as the canonical base for all
         * your application's URLs. This is useful when the environment
         * observed in the server differs from the one observed by end users,
         * for example, when using a load balancer to offload TLS.
         *
         * Note that this configuration option does not allow setting a path as
         * part of the URL. If your setup involves URL rewriting or any other
         * tricks that would result in SimpleSAMLphp observing a URL for your
         * application's scripts different than the canonical one, you will
         * need to compute the right URLs yourself and pass them dynamically
         * to SimpleSAMLphp's API.
         */
        'baseURL' => 'https://'. $_SERVER['HTTP_HOST'],
    ],

tsega → created an issue.

Just a few observations regarding your changes:

1. Your base branch was 1.0.x one but it should be the tag 1.0.0-alpha3
2. The removed check (lines 147-149) are exactly what is required to stop the execution of the second foreach, i.e if the $workflow variable is not continue (skip) to the next step of the 1st loop (line 144)
3. What you have changed does not actually execute:
   

   if ($workflowType === null) {
     continue;
   
     foreach ($states as $state) {
       $exploded = explode(':', $state);
       if ($exploded[0] != $element_id) {
         if (!$workflowType->hasTransition($transition_id)) {
           continue;
         }
   
         $transition = $workflowType->getTransition($transition_id);
         $settings['states'][$transition_id] = $transition->label();
       }
       return $summary;
     }
   }
   

   Every time the $workflowType === null condition is met, i.e. the $workflowType is null, the continue keyword would skip the forloop and go back to line 144.

   The rest of the code block there will never execute.

Possible Solution

The check you introduced should be written as follows:

// See Drupal coding standards recommendations https://www.drupal.org/docs/develop/coding-standards/write-e_all-compliant-code
 if (is_null($workflowType)) { 
    continue;
 }

// The reset of code

@chentan11 Thanks for the MR but honestly I'm 100% sure if we're addressing the same thing. Can you please explain what your changes are doing?

Patch with proposed solution

tsega → created an issue.

Adds the check for the $workflowType not to be null.

tsega → created an issue.

Here is a patch to fix this.

tsega → created an issue.

Hi @Yan2020, you need to use the user's email field not the user's name or ID. Please try that and let me know. If this doesn't work I create a patch for this.

Hi Jaafar,

Apologies for the late reply.

If you have used composer to install the module then the dependencies will be installed automatically.

The error message you shared is a simple deprecation warning. If you're getting a 500 Error then you should probably look at your web server logs (Apache or Nginx) - I suspect you might need to update some of the server settings.

I'm willing to help out if you still want to explore this.

@jfox77 did you figure out where the questionnaire information (answers) are being saved?

Hi Orkut,

I will work on this coming few days!

Thanks for the request.

Thanks for the patch, it works!

I believe with a large number of users, classes and trainings the add member form takes a very long time to load the user list; somewhere around > 3minutes. The site I'm working on has about 9K users.

This results in very poor user experience.

I am looking for ways to limit the initial load of users, e.g. 100 unfiltered users then as the user types in the search box fetch filtered users again limited to 100. Same thing goes for Class and Member filter.

@No Sssweat, thanks for these awesome patches!

One change to the patch that updates the Progress class #certificate_url ( adds-user-to-cert-pdf-route-3280394-3-opigno_learning_path.patch → ), the user id to use should be picked from the $accounrt_id not from the $uid (current user id).

I can confirm that the patch at #24 works with v6.0.3 of Better Exposed Filters.

Thanks @a.kovrigin!

Patch #3 works, would be great if it get added in the next release.

I can confirm that patch from #7 🐛 Notice: Undefined index: format in Drupal\message\Entity\MessageTemplate->getText() Fixed works.

This incompatibility is cause by the fact that opigno/opigno_lms has a hard dependency on drupal/core: 8.9.20. See dependencies on Packagist.

I'm guessing drupal/ckeditor_font dev-1.x has moved its dependency to drupal/core ^9.3 || ^10 because it a dev version and does not guarantee compatibility.