The Official Blog for LifterLMS Contributors

  • LifterLMS Version 3.30.0-beta.1

    • Added options to customize the checkout redirect behavior for each access plan
    • Updated LifterLMS Blocks to 1.3.8. Fixes an issue causing some installations to be unable to use certain blocks due to jQuery dependencies being declared improperly.
    Read more: LifterLMS Version 3.30.0-beta.1
  • LifterLMS Blocks Version 1.3.8

    • Explicitly import jQuery when used within blocks.
    Read more: LifterLMS Blocks Version 1.3.8
  • LifterLMS ConvertKit Version 2.1.0

    Updates
    • Important: This update raises the LifterLMS Core version requirement to 3.29.0. Please upgrade the LifterLMS core if you haven’t already done so.
    • Added an option to allow LifterLMS native ecommerce purchases to be synced to ConvertKit using the ConvertKit purchases API, enabling automations based on purchases.
    • Added additional options when using LifterLMS with WooCommerce to ensure consenting customers are subscribed via LifterLMS ConvertKit registration and enrollment automations.
    • Added custom field mapping to allow automatic population of ConvertKit custom fields with data from LifterLMS registration, checkout, and enrollment fields.
    • “Consent” requirements may now be disabled a single line of code: add_filter( 'llms_ck_enable_consent', '__return_false' ).
    • API errors are now logged to a “convertkit” file isolated from the main LifterLMS log file.
    • Improved data validation for all settings submitted via forms on the admin panel.
    • Reorganized the settings screen for increased visual clarity.
    Bug Fixes
    • Fixed a LifterLMS core 3.29.0 compatibility issue preventing consent from being saved properly during new user registration via the checkout/enrollment screen.
    • Resolved an issue allowing the consent and unsubscribe notice message options to show as empty or blank on the integration settings screen.
    Deprecated Functions

    These functions, methods, and classes have been marked as deprecated and will be removed during our next major update. Custom code should be modified to use replacements as soon as possible.

    • Deprecated LLMSCK(), use LLMS_ConvertKit()->api() instead.
    • Deprecated class LLMS_ConvertKit_Api, use LLMS_CK_API instead.
    Read more: LifterLMS ConvertKit Version 2.1.0
  • A (late) Introduction to the LifterLMS Working Group

    Saurabh had an idea

    He approached the team sometime in the fall. He wanted us to start a LifterLMS Working Group.

    In software development working groups are common. The W3C has several dozen groups which regularly gather to discuss and work on various internet specifications. Without these groups and specifications, we would not have many of the tools and utilities we use daily to power our websites.

    WordPress itself doesn’t call them working groups, but if you point your browser to make.wordpress.org you can see another dozen or so teams working on various areas of the WordPress project.

    A free and open-source project with a growing community should have it’s own working group, but we don’t.

    We’ve always planned features with the interest of the user in the forefront of our minds. We gather feedback and diligently record issues and feature requests. We pivot our focus and goals based on these comments and questions we hear in support conversations and social media posts.

    But the issue Saurabh’s idea attempts to resolve is that we did not have an official forum or platform to facilitate the co-creation of LifterLMS. We, the core team, have always remained solely responsible for the actions taken following or as a result of these conversations.

    Saurabh’s idea was to gather a new group of stakeholders and meet to organize our collective thoughts about the successes and shortcomings of the project. His idea was to create the platform the project has been lacking.

    The First Meeting

    In January we organized the first meeting of this working group. We hand-selected a small group of users and contributors. We decided to start with quizzes as our first discussion topic. We checked our issue and request trackers and found when organized by category, quizzes, by far, had the highest number of feature requests.

    I had intentions to distill the learnings of this first working group into some ground-breaking document and publish it here on the blog.

    I had intentions that something so powerful would be said that it would result somehow instantly in a reconstructed and superior quiz system.

    We discussed these things, and we (the core team) recorded more notes and more feedback. A lot of what we talked about has been written down and recorded by us multiple times over. New points were brought to our attention, and some of the issues we’re aware of were given new context.

    There’s more work for our team to do on quizzes, and as we approach the second meeting of the working group we have new things to consider.

    Improving the Working Group

    As we look forward to the next session of the group, we hope to work together to find ways to encourage greater participation from members of the group.

    Talk and discussion is not unimportant, but it’s only a small part of what we’ve learned we need from this group. We not only need members with great ideas and strong opinions, we need members who are willing to do work.

    The most obvious work is code, but we don’t need to write more code*, we need to draft and create documentation, architectural models, feature concepts, roadmaps, and design specifications.

    In simple terms: we need to determine, concretely, the things that LifterLMS needs to do. We need to write these things down and commit to them.

    After these concepts and ideas are solidified, then I will work with our core team and contributors to turn these into deployable and useable features.

    If we look to the work of the working groups of the W3C, we’ll see that these groups do not write code. They write specifications. These groups may have developers in them but the primary purpose of these groups is to create and design these specifications. The browser vendors and developers working on Chromium or Blink or Mozilla will then interpret these specifications and create the browsers we use.

    Moving forward, the LifterLMS Working Group will be creating these specifications, and you’re invited to participate.

    * If you’re a developer, we do need to write more code, please join us, please contribute.

    Session 2, March 2019: Certificates

    On March, 20, 2019 at 9:00am PST we’ll gather for the second session of the LifterLMS Working Group, and we’ll be discussing certificates.

    Our choice for this session comes after realizing that our first topic, quizzes, was perhaps too broad a topic. Certificates, while arguably as important as quizzes, we’re hoping will prove to be a topic that’s more digestible in a short period of time.

    Bring your ideas, and be prepared to start creating LifterLMS with us.

    See the events calendar for meeting details.

    Read more: A (late) Introduction to the LifterLMS Working Group
  • LifterLMS MailChimp Version 3.1.1

    • Fix an issue preventing grouping and tagging during new user registration on the enrollment/checkout screen.
    Read more: LifterLMS MailChimp Version 3.1.1
  • LifterLMS Version 3.29.4

    • Fixed an issue preventing users with email addresses containing an apostrophe from being able to login.

    v3.29.3 – 2019-03-01

    Bug Fixes
    • Removed attempts to validate & save access plan data when the Classic Editor “post” form is submitted.
    • Fix issue causing 1-click free-enrollment for logged in users to refresh the screen without actually performing an enrollment.
    Template Updates
    Read more: LifterLMS Version 3.29.4