Using GitHub for WordPress Plugin Development

Over the years I have developed several different plug-ins for WordPress, and contributed them to the plugin directory. In that time, many things have changed about source code management, while WordPress has not moved on.

For those that don’t know, the WordPress plug-in directory is still using SVN (Subversion) for submitting plug-ins. Back 2012 when I first submitted a plugin, this was perfectly fine. SVN will still very popular, SourceForge was the king of open source software version control repositories, and life was good.

Fast forward to 2023, and well, that’s not so much the case anymore.

GitHub has become a huge repository of open source source code and has featured that SourceForge could never dream of.

While there has been some consternation around Microsoft’s purchase of GitHub, that doesn’t seem to have had a major impact so far.

So what’s the best way to use GitHub if you’re doing plugin development?

Well, GitHub Actions are going to be your best friend.

I won’t cover the basics of using Git here, you’re probably well familiar with it if you’re reading this post. But there are two issues that GitHub Actions can help you solve when hosting your plug-in on GitHub:

  • Generate a
  • Deploy a release to

Auto Generate a from readme.txt and GitHub use two different standards for their readme files, and while GitHub will display a readme.txt file, it will look very ugly. To fix this, you need to create and maintain a version of your readme.txt file, but that’s a manual task, unless you use GitHub Actions and a bit of grunt magic.

The first thing you’re going to want to do is make sure npm is installed, your distro should have it in the default software repositories:

npm --version

If you get an error, go figure out how to fix it.

Now you want to create a file called “package.json” in the root of your plugin git repo, add the following content to it:

  "devDependencies": {
    "grunt": "~1.5.3",
    "grunt-contrib-jshint": "~3.2.0",
    "grunt-contrib-nodeunit": "~4.0.0",
    "grunt-contrib-uglify": "~5.2.2",
    "grunt-wp-readme-to-markdown": "^2.1.0"

This tells npm that you want to install some packages here, the important one is grunt-wp-readme-to-markdown which will create a markdown version of your readme.txt file.

Now create a “Gruntfile.js” in the same directory:

module.exports = function(grunt) {

  pkg: grunt.file.readJSON('package.json'),
  wp_readme_to_markdown: {
	convert: {
	    files: {
	      '': 'readme.txt'
	    options: {
			screenshot_url: 'assets/{screenshot}.png'


grunt.registerTask('default', ['wp_readme_to_markdown']);


This file tells grunt what to do, in this case, run the readme converter. Note the options line, if your screenshots are somewhere other in an “assets” folder in the root of your git repo, you can change this line to point to the right location. See the grunt-wp-readme-to-markdown for details.

One last file to create here, if you don’t already have one, is “.gitignore”, add the following lines to it:


Ok, now it’s time to try converting your readme.txt to

npm i

The first line tells npm to install the modules you included in package.json, this might take a few minutes depending upon your connection. The second tells grunt to run the default action.

You should see output something like this:

added 245 packages, and audited 430 packages in 24s

npm -i
3 packages are looking for funding
  run `npm fund` for details

51 vulnerabilities (5 low, 15 moderate, 20 high, 11 critical)

To address issues that do not require attention, run:
  npm audit fix

To address all issues (including breaking changes), run:
  npm audit fix --force

Run `npm audit` for details.

Running "wp_readme_to_markdown:convert" (wp_readme_to_markdown) task
File "" created.

Done, without errors.

You may see additional warnings based upon your distro, but as long as it doesn’t generate an error you should be fine.

You should now have a nicely formated MarkDown version of your readme.txt.

This is good, but it kinda sucks having to generate and commit it each time you update your readme… so this is where GitHub Actions come in to play.

Now create a directory called “.github/workflows” in the root of your repository. Then create a new file there called “readme-md-generator.yml” with the following content:

name: Generate from readme.txt

    branches: [ "main", "master" ]
    paths: [ "readme.txt" ]

    runs-on: ubuntu-latest

        node-version: [18.x]

    - uses: actions/checkout@v3

    - name: Use Node.js ${{ matrix.node-version }}
      uses: actions/setup-node@v3
        node-version: ${{ matrix.node-version }}

    - name: Build
      run: |
        npm install
        git config --global '${{secrets.GIT_USERNAME}}'
        git config --global '${{secrets.GIT_EMAIL}}'
        git commit -am "Regenerate"
        git push

This action will regenerate your file every time readme.txt is committed to the main/master branch of your plugin, and then commit it back to your repo.

Before you can run this action though, you need to create two secrets in your repository:

  • GIT_USERNAME: Your GIT username (usually something like “First Last”)
  • GIT_EMAIL: Your GIT e-mail address

Go over to your GitHub repo settings and find Secrets->Actions to set these two values up. Make sure to do this before committing the rest of the changes to your repo, otherwise the GitHub Action will fail the first time it is run.

Now you can commit all of the above changes to your repo. If you want to recover some local space, you can remove the “package-lock.json” file as well as the “node_modules” if you don’t want to manually generate the file in the future.

Once commited, the file should be generated every time you make a change to the readme.txt file on GitHub.

Note: if you do not commit a file (with or without content) the Action will not work as it expects a file to already exist in the repo. Simply create an empty one and commit it to the repo.

Deploy a release to

Once you have readme file auto generating, the next big issue is deploying to Fortunately 10up has created a GitHub Action to do this for you.

Your first step is to create two additional secrets for your repo:

  • SVN_USERNAME: Your SVN username on
  • SVN_PASSWORD: your SVN password on

Now you can create another Action in your repo under “.github/workflows” called “wordpress-plugin-deploy.yml”:

name: Deploy to
    types: [published]
    name: New release
    runs-on: ubuntu-latest
    - name: Checkout code
      uses: actions/checkout@v2
    - name: WordPress Plugin Deploy
      id: deploy
      uses: 10up/action-wordpress-plugin-deploy@stable
        generate-zip: true
        SVN_USERNAME: ${{ secrets.SVN_USERNAME }}
        SVN_PASSWORD: ${{ secrets.SVN_PASSWORD }}
    - name: Upload release asset
      uses: actions/upload-release-asset@v1
        GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        ASSETS_DIR: assets
        upload_url: ${{ github.event.release.upload_url }}
        asset_path: ${{ }}
        asset_name: ${{ }}.zip
        asset_content_type: application/zip

This action will deploy a new version of your plugin to every time you create a release on GitHub. It will also generate a zip file an attach it to the GitHub release for you.

Of note here is the “ASSETS_DIR” variable, just like with the screenshots on the generator, this is the location of your assets. If they are somehwere else, set this variable to that directory.

You can also setup this Action to fire when you tag your code instead of release it, you can see more details over on the WordPress Plugin Deploy page.


And that’s it!

You now have an automated way to generate for GitHub and automated deployment to for your plugins.

There are a few other things that could be automated with GitHub Actions:

  • 10up has the “ Plugin Readme/Assets Update” Action, however I have a php script to do this separately.
  • Readme and plugin version updates on release. At the moment you have to manually update your plugin version, both in the plugin file as well as the readme. This could probably be automated with an Action during the release Action.

Update for: WordPress and Gutenberg: 20 Things That Need To Be Resolved

It’s been 9 months since my original post about Gutenberg and I thought it was time to make some updates.  I’ll keep this as a bullet list and only include things that have changed:

  • I’ve been using Gutenberg on more of my sites and it has improved since my last post.
  • 3. Settings saved in cookie instead of database, this has finally been fixed in a recent release!
  • 10. Clicking “Switch to draft” uses a JavaScript alert box instead of a proper React model box, fixed!
  • 13. No background/highlight support in paragraph blocks, now available through the overflow menu!
  • 19. Calendar widget doesn’t work well with the mouse, this has partially been fixed, a more robust calendar pop-up is available, however it still has some limitations, like the month is a drop-down select, but day and year aren’t.
  • 20. The default block selector, this looks to be much better than it was before, perhaps it might have just had more time to learn the common blocks I use.

While the above fixes are appreciated, there is still a lot of work needed to make Gutenberg a good writing experience, even if it has improved as an editing experience.

In my conclusions in my original post I said:

In fact, I’ve written this article in the classic editor and even with it being complex and long, it was much less frustrating than the last thing I tried to write in Gutenberg.

Which I still find true, if I have any significant content to create, I write it in something else and then past it into Gutenberg.

WordPress and Gutenberg: 20 Things That Need To Be Resolved

So I’ve been avoiding Gutenberg since it pretty much came out, using the Classic Editor plugin to disable it on all the sites I manage.  However recently I was working on a new site and decided to give it a try and see what the experience was like.

A bit of background on how I was using it first:

  • The site had a recurring schedule of posts that were mostly text with a few images.
  • Posts were anywhere from short “news” style posts of a few dozen words to longer “articles” that were a few hundred words long to a few thousand.
  • Pages were mostly static but included some shortcodes and other block styles.

The following list is in no particular order, other than similar items are grouped together.

1. The “Save draft” and “Preview” buttons look like links

I really can’t express how much this bugs me in WordPress in general, and Gutenberg has continued on in the same tradition.  Links and buttons should be distinguishable by looking at them.

These two aren’t the only offenders, but they stick out like sore thumbs to me.

2. “Save Draft”/Preview/Publish text vs gear icon vs more menu

This is the standard Gutenberg toolbar:

Take a look at that, four different kinds of buttons all in a single toolbar, side by side:

  1. The aforementioned “hyperlink” style buttons (Save draft/Preview)
  2. A traditional “labeled” button (Publish)
  3. An icon button with border/background (gear)
  4. A button without any border/background (overflow/more)

Pick a style and stick with it!

3. Settings saved in cookie instead of database

As far as I can tell, your Gutenberg settings are stored in a cookie in your browser instead of in the WordPress database.  This means that if you go to a new browser/PC or clear your cookies often, you lose your preferences.

Settings should be stored more persistently than that.

4. The revisions accordion

Gutenberg has an entire accordion section reserved for “Revisions” that doesn’t act like an accordion block.  This use to be in the “Publish” widget, which is now the “Status & visibility” accordion, why isn’t it there in Gutenberg?

Are revisions that critical that it needs to be at a top level element instead of part of another one?

5. 4 finger salute for keyboard shortcuts

Many of keyboard shortcuts in Gutenberg are cumbersome, want full screen mode?  Ctl+Shift+Alt+F… what?

I get it, lots of single combos are taken up by the browser (Ctl-F is find, Alt-F brings up the browser menu, etc.) but really?  Four a finger salute?

And full screen mode is not the only offender either, there’s a mix of three and four finger shortcuts for little reason.  Standardize on three and work it out already.

6. Block toolbar in default “floating” mode

The floating block toolbar often gets in the way of adding new blocks between existing blocks.  For example:

You can add a bock below the current block, but if you try and hover between the current block and the one above it to reveal the add block button, it doesn’t work.

Wouldn’t the default position of the toolbar be better if it was vertical instead of horizontal and was attached to one of the sides of the block instead of the top of it?

7. Ctrl-Home/End don’t work as expected

Ctrl-Home/End should take you to the top/bottom of the post but instead just take you to the end of the block while shifting the viewport (kinda like having scroll lock on).

8. Categories and Tags have different UI’s but virtually identical functionality

This bugged me in the classic editor too, but it’s worse now only because there was a complete rewrite and nothing changed.  Categories and Tags are very similar, but have different UI’s in the editor.  Categories are checkboxes and tags are a “cloud”.  But you create and mange categories and tags through the admin in exactly the same way.

Just like there is a unified backend management of categories/tags, there should be a unified interface to add them to a post.

9. Tags auto create new tags with no notification/warning and often do so unintentionally

Similarly, because the UI for adding tags doesn’t list out all the tags you can select, when you add a “new” tag to a post it is automatically added to the backend if it doesn’t exists already with no confirmation.  This creates the situation where you may mistype a tag name (misspell it or something) and it is instantly added to your tag list.

There should be a confirmation when adding new tags or at least when you then remove the new tag from the tags UI in the post it should remove it from the backend as well.

10. Clicking “Switch to draft” uses a Javascript alert box instead of a proper React model box

So let me get this straight, you build a completely new UI from the ground up in React to edit posts, and you leave one dialog box in the default Javascript popup style?

11. Featured image should be set to the first image added to the post by default (or at least a popup message to do so)

This one is pet peeve, if your theme supports featured images, wouldn’t it make sense to set the first image you add to a post to be that featured image?  Or a least a popup to ask if you want to?

12. No drag and drop for rearranging blocks

This is a bit of a fake complaint, there is drag and drop for rearranging blocks… as long as you don’t dock the toolbar to the top of the page.  You should be able to select any border of a block and drag and drop it instead of just a single (non-intuitive) control handle inside the block toolbar.

13. No background/highlight support in paragraph blocks

This is a staple of pretty much every WYSIWYG editor on the planet.

14. No font support for paragraph blocks

This is a staple of pretty much every WYSIWYG editor on the planet.

15. Shortcode block has no preview or even a drop down list of shortcodes that are available

The shortcode block is a shell of a block.  Do I need to add the []’s in?  What shortcodes are available?  How about a preview?

Some of these are technically challenging, preview the most obvious.  May shortcodes do not generate valid HTML blocks as they expect to have other shortcodes to complete an HTML block, so those would break Gutenberg.

But that doesn’t mean you couldn’t do something, like add a block setting for it with a dropdown of all the registered shortcodes at least.

16. Stats are hidden away in the info button

The “Details” button (which is an I with a circle around it for some reason…) hides the statistics like word count and block count, making a user have to click to get to them.  Where as, by default, there is a big long breadcrumb section at the bottom of the Gutrenberg frame that could contain some of these details for quick “glance” style access to the information.

17. “Publish: Immediately” when clicked uses the creation date

What date/time do you think you would see if you click a link titled “Immediately”?  Perhaps the current time and date?

Well in Gutenberg you’d be wrong.  For some reason Gutenberg believes that the post creation date/time is a better thing to display than the current date/time.  This is counter intuitive, especially as if you then hit “Reset” in the calendar control it will use the current date/time if you click on “Immediately” again.

18. Prepublish checklist/Publish should include a check for post dates in the past and issue a warning.

This is tied in to the previous issue, because the creation date is used, if you go to publish a post and update, say the month, but don’t notice that the year is wrong guess what’s about to happen.

This happened several times as I’d started drafts in late 2020, but didn’t schedule their publish date/time until early 2021.

There are times when you want to publish a post in the past, but it seems very rare to me.  Having a simple check on the publish date/time and making sure it’s in the present/future seems like a logical thing to do.  If it’s in the past, popup a warning/confirmation dialog just to be sure.   There could be a “don’t ask me again” checkbox included to ensure it doesn’t become burdensome to those that actually do post things in the past on a regular basis.

19. Calendar widget doesn’t work well with the mouse

And speaking of the calendar control… there are a pile of issues with it:

  • Changing the month pulldown doesn’t update the calender until the focus changes
  • 24 hour time isn’t supported
  • Changing the hour to any value automatically assumes AM even if PM is currently set
  • There is no way to change the hour/minute with the mouse
  • Clicking on AM/PM/calendar closes the control instead of letting you continue to modify the date/time
  • The timezone offset is underlined but not clickable (if it’s displayed)
  • Calendar help is way to skinny/long

20. The default block selector

When adding a new block, a list of commonly/recently used blocks is displayed, but the algorithm behind it seems kinda braindead.  Blocks I use often don’t appear, or do appear for a short while and then fall off the list again.  Blocks I’ve never used seem to hang around or come back randomly.


Overall, there are still a lot of ruff edges in Gutenberg, and with the focus on full site editing, it doesn’t look like a lot of polish is being done to it as a post editor.  There is some progress happening though, for example the closing of the calendar control when clicking on a date has been fixed in development, so it should show up in WordPress 5.8.

In the end though I’m not convinced that Gutenberg produces a particularly good writing experience, and that what post editing is supposed to be about.

In fact, I’ve written this article in the classic editor and even with it being complex and long, it was much less frustrating than the last thing I tried to write in Gutenberg.

I think that sums it up pretty well really.

Improving Thunderbird on Linux


As it should be apparent by now, I’ve completely moved off of Windows and moved to Linux for my servers and desktops.  As part of that move I had to find a new mail client, as Outlook has been my go to app for years.

The obvious choice is Thunderbird, its cross-platform and is mature, supporting everything I need, including contacts and calendar from NextCloud.

Unfortunately, the default configuration of Thunderbird on Linux looks a little… well.. terrible to be honest:

This might have been acceptable 10 years ago, but in comparison to a modern version of Outlook, it’s hard to take that big of step backwards.

But what if it could look like this instead:

Well that looks a little better doesn’t it?

To accomplish this there are several steps/requirements:

  • You must be using Thunderbird 60 or above.
  • You have to be comfortable editing TB’s advanced settings.
  • You have to install a custom theme/add-on.
  • You have to customize the toolbars.
  • And add a few extensions and other settings as well.

So here’s each step broken down.

Note: This guide is for Linux, but all of the below customizations should work on Windows as well, but I haven’t tested them so try at your own risk.

Install Thunderbird 60

I’m not going to go in to any detail on this, your distro will probably already have a package all ready for you, so either go to your software store or command line and download it.

If you’re not sure which version is installed, just go to the Thunderbird Menu -> Help -> About dialog and it will be there for you.

Hiding the Application Title Bar

One of the most annoying things about Thunderbird and Firefox is that on Linux, by default, they don’t use client side decorations (the min/max/close buttons) and therefore require the application title bar to be present, wasting screen real estate.

For Firefox, there’s a simple check mark in the customization screen to either enable or disable the title bar, but Thunderbird for some reason decided not to add that.  It still has the functionality, just not the UI to make it easy to enable.

So, as per this helpful article, do the following:

  1. Go to the Thunderbird Menu
  2. Select Preferences -> Preferences
  3. Select the Advanced tab and the General sub tab
  4. Click the Config Editor button near the bottom
  5. If this is your first time running it, accept the warning and tell it to go away for good 😉
  6. In the search field, enter (without the quotes) “mail.tabs.drawInTitlebar”
  7. Double click on the preference name in the list below and Thunderbird should now be titleless (you may need a restart if it isn’t)

Adding A New Theme

This is a little tricky, because if you’ve ever added a theme before, we’re not going to do it that way.

Instead, what we’re really going to do is add an extension:

  1. Go to the Thunderbird Menu
  2. Selection Add-ons -> Add-ons (the add-on manager should be displayed)
  3. In the left had menu, select Extensions
  4. In the search field at the top right, enter “Monterail” (again, without the quotes)
  5. Three items should show up in a new tab:
    1. Monterail (a blue coloured theme, but has some issues with add-ons like Lightning due to contrast)
    2. Moterail Dark (the version I used in the screen shot above)
    3. Monterail Full Dark (makes the message list background dark as well)
  6. Select “Add to Thunderbird” for the theme you want to use
  7. Restart Thunderbird

When Thunderbird restarts it will be using the selected theme, and if you go to the add-ons page you’ll notice that there is no extension that matches the new theme, but instead it is listed under Themes.

Customize Your Toolbars

This is probably the easiest part of this change, but the most tedious as well, all of the below are optional and you may select which ones you want to add, step one is to open the customizer by right clicking on the toolbar and select Customize, then:

  • Move the Thunderbird menu all the way to the left
  • Add a divider between the Thunderbird menu and the first item
  • Remove the Get Messages, Chat, Address Book, Tag, and Quick Filter buttons.
  • Add Reply, Reply All, and Forward buttons
  • Add another divider
  • Add the File and Delete buttons
  • Add a divider
  • Add the Print button
  • Add a divider
  • On the right of the search bar, add a spacer

Once that is done, at the bottom of the customizer window should be a “Show:” combo box, select “Icons and Text” and then close the customizer.

Now, go and open and e-mail and repeat pretty much all of the above and remove the duplice buttons below the message toolbar as well 😉

Extensions And Other Settings

In addition to the above, there are a few other extensions you may want to use:

  • Hide Local Folders: By default Thunderbird shows some local folders to support POP accounts, but if you don’t have any, they’re redundant so this extension hides them from the list.
  • FireTray: Thunderbird doesn’t have a very good way of showing new mail, this extension adds a gnome tray icon which you can customize.  unfortunately FireTray hasn’t been updated for Thunderbird 60 support yet (and may never be), fortunately someone else has forked it and updated.  unfortunately it’s not in the Thunderbird Extension store yet, you’ll have to grab it from the GitHub Repo directly.
  • LookOut (fixed version): If you’re sending messages back and forth with Outlook users, this will add support for Microsoft’s proprietary message extensions.
  • CardBook: For getting your contacts from NextCloud or other CardDAV servers.
  • Lightning: For getting your calendar from NextCloud or other CalDAV servers.

There are a few other settings you might consider:

  • Hide the message pane via Menu -> Preferences -> Layout -> Message Pane
  • Hide the Quick Filter bar, either by clicking the button before you remove it above or via Menu -> Preferences -> Quick Filter Bar
  • Open messages in a new window via Menu -> Preferences -> Display -> Advanced
  • Close message window on move delete is the same place as above
  • Disable the crash reporter via Menu -> Preferences -> Advanced -> Data Choices

What Else Could Be Improved?

After you finish with the above, you’ll have a much better Thunderbird experience than you get out of the box, but it’s not perfect:

  • The message list is from the 90’s (ok, maybe the 2000’s).  Specifically each field is one column in the list, which makes poor use of the horizontal space.  Outlook moved away from this years ago.  Unfortunately we’re going to have to wait for Thunderbird to fix it themselves as the research I did seems to be pretty clear an add-on can’t fix this.
  • When you compose a message, you get the full, ugly drop down menu at the top of the window.  I did find a plugin that hides it, but not until after it’s been displayed so I don’t think that’s better.
  • The hamburder menu is ugly, this isn’t specific to Thunderbird, I just think all hamburger menus are ugly.  The “blue” Monterail theme does replace it with a little Thunderbird logo, so it is possible to change, but it looks like a complete new theme is required to do so.
  • Remove the tabs.  I know most people like them, and for a web browser they probably make sense, but for a mail client they just rub me the wrong way.  Being able to disable them would be nice but I don’t expect it to happen.

And that’s it… happy Thunderbirding!


Android Apps


When I first replaced my Windows Phone with Lineage, I gave a summary of the software I was using with it.  Well, it’s been a year and so it’s time to give an update…


When I first used Lineage I installed a minimal set of Google apps, but having just installed Lineage 15.1 on a new phone I’ve decided against install GAPPS.  This has come with a few drawbacks, apps that either warn you that they don’t run without GAPPS (but often still work anyway) to a few (like KAYAK) that just crash after loading.

It seems like a reasonable trade-off though as almost all of the apps I’ve found that don’t work have websites that do.

App Stores

Initially I used F-Droid and 1Mobile for my app stores, but I’ve moved away from 1Mobile.  I found too many issue with it.

To replace it, I’m using Yalp Store, which pulls apks straight from Google Play (obviously only free apps).

The Launcher

Trebuchet has come a long way with Lineage 15.1 and while previously I had installed Nova launcher, I’ve decided to give Trebuchet a try for a while.

The Keyboard

AnySoft Keyboard is still my go to keyboard  Nuf said.


  • Weather: Forecastie isn’t the slickest weather app around, but it has a good widget for the home screen and is completely open source.
  • Music: I have been using Phonograph for quite a while, but it’s recently implemented a “Pro” pay version.  This has caused it a bit of a stir in the open source project and a fork has been made, Vinyl.  The other benefit to Vinyl is that it is on F-Droid.
  • Mapping: osmAnd~ is an open source mapping solution.  I used it last year on a trip to the southern US without any issue.
  • Passwords: Still using Keepass2Android.
  • Bluetooth Connections: Stock Android doesn’t seem to remember volume settings for different Bluetooth devices, so I installed A2DP from the F-Droid store which allows for complete customization of what happens when a Bluetooth device connects to the phone.
  • Mail: I’ve gone though several mail clients, but I’ve landed on K9, while it has a very outdated visual design, it is extremely functional.
  • BrowserFirefox, along with Ghostery.
  • Office: LibreOffice Viewer handles any office file formats I need to view.
  • Twitter: Twidere is a nice open source client for Twitter, it also supports several other social networks as well.
  • Two Factor Auth: Several sites I login to use OTP, so andOTP is my go to client for them.
  • Gallery: Lineage’s default gallery app has one major limit, no ability to exclude folders, so instead is use Simple Gallery.
  • Birthdays: Birthday Droid keeps me up to date for upcoming birthdays.
  • Music Store: I don’t subscribe to any streaming music services, but I do use the 7 Digital music store to purchase any music I want.
  • Contacts/Calendar Sync: Having moved away from MS Exchange to NextCloud for my calendar and contacts means I need something to sync them to Android, DAVdroid works flawlessly.
  • Torrents: Ok, so I don’t do much torrenting on my phone, but once in a while in an emergency I have had need to, so LibreTorrent is installed.
  • PDF: MuPDF is my PDF viewer.
  • Tasks: OpenTasks is the recommended task app for DAVdroid.

I’ve also installed NextCloud and the related apps.