Add Markdown table support and corresponding test

[ahmedasar00]

• Added support for Markdown tables in Entry model.
• Added a test case (test_markdown_table_conversion) to ensure proper HTML conversion of Markdown tables.

Fixes #2314

[ahmedasar00]

Hi @thibaudcolas, @sarahboyce — I’ve added support for Markdown tables in the Entry model and included a test case (test_markdown_table_conversion). The PR is ready for review. Thanks!

[sarahboyce]

Looks great!
Thank you for adding a test ❤️ tests make me really happy 🎊

[adamzap]

This is very close!

[adamzap]

These two lines are doing the same thing. The first section of the documentation on extensions shows multiple ways to specify an extension:

markdown.markdown(some_text, extensions=[MyExtClass(), 'myext', 'path.to.my.ext:MyExtClass'])

So we can just pass in "tables" here since we're not customizing the extension.

[ahmedasar00]

Thanks @adamzap for the clarification! Removed the duplicate tables extension and now using "tables" shorthand as no customization is needed.

[adamzap]

@ahmedasar00 CI is failing because you no longer need this import.

[ahmedasar00]

Thanks @adamzap for pointing that out! I've removed the TableExtension import and usage because it's no longer needed—using the "tables" shorthand works fine and avoids import issues. CI should pass now.

[adamzap]

👍 Looks great!

[ahmedasar00]

Hi @adamzap , @sarahboyce

Thank you so much for the helpful review and guidance on this PR — I really appreciate the clarity of your feedback.

As someone who’s still learning how to contribute effectively to Django, I’d love to ask (if you don’t mind): do you have any advice or recommendations on how I can improve my future contributions, whether in code quality, tests, or choosing good issues to work on?

Your experience and work on the project are truly inspiring, and any guidance would mean a lot to me.

Thanks again, and really appreciate your time!

[sarahboyce]

This was a good issue choice 👍
Having written a test, this already puts you in the top 20% of contributors in my opinion
If you want me to give minor nitpicks:

• I added "Fixes [github issue link]" into the PR description for you to have this PR be linked to the issue in such a way that when this is merged, the issue gets closed
• it is nice to add an image to your PR description when appropriate to let folks see the changes in action (and give extra confidence in your manual testing)
• install the pre-commit or run linters manually before committing
• squash/rebase to have a clean git history (this is my preference but I'm biased based off django/django contributions)

[adamzap]

@ahmedasar00 Thank you for the kind words and also for your contribution!

In addition to what Sarah said:

• Spend time learning the architecture, patterns, and style of the project you want to contribute to without looking for anything specific to change. The better you know the project (or part of the project) that you are contributing to, the easier it will be for you write code that fits naturally. For example, you could just study the blog app of djangoproject.com or the contrib.sessions app of django to start. This will help you to grow as a developer in general as well.
• Try your best understand the issue and its scope before opening a pull request. Ask clarifying questions or propose an approach on the issue if there is ambiguity. We are all trying to understand open issues better.
• Imagine yourself as the person that will review your pull request. How best can you accommodate the reviewer and make the review process pleasant? Honoring the maintainers of a project keeps things efficient and sustainable. You may find yourself as the maintainer of an open source project one day!
• Be patient with the maintainers and know that larger or more obscure pull requests will probably take longer to get a review.

[ahmedasar00]

Thank you very much, @sarahboyce and @adamzap! I really appreciate your time, support, and valuable feedback. 🙏