ismail-s / fireblog Goto Github PK

Maybe use https://github.com/nvdv/vprof to find slow parts.

Atm, whenever personatestuser.org goes down, the tests fail. It would be much better to instead mock out the functionality. This would probs also speed up the tests.

Atm, there is initialize_fireblog_db and uwsgi, one for upgrading/checking/setting up db and one for running the website. It would be good to combine the 2 into one grand command which takes as input an ini file and does whatever it is told to do.

See http://github.com/pylons/paginate_sqlalchemy

When updating, any new deps need to be installed first. I see 2 ways of doing this:

1. After checking for updates, install new deps in a uwsgi task
2. When the user chooses to update, then first install any new deps, then switch to latest code and reload

The latter sounds easier to do, IMO, and it is done at a point when it is expected that things will take some time. Also, in the future, we could send updates on the progress of the update whilst it is happening to the admin who initiated it.

• Get the views to work with a sorting parameter
• Update templates to display sorting select box and to handle changes to this box
  • Bootstrap
  • Polymer
  • Simple
• Test everything
  • Make sure default sorting is newest first
  • Make sure sort oldest first works
  • Make sure sort newest first works for page 2
  • Make sure sort oldest first works for page 2
  • Make sure sorting urls generated for both views are correct
  • Make sure templates work for both sorting orders (ie functional tests)

In various places, there are imports with try...except to deal with Python 3.2. We should have a single file to deal with this.

Once uwsgi integration has been achieved, then work can start on restarting the blog programmatically.

This is a bit of a generic issue, but there are various places in the blog where things can mess up in ways that won't be nicely handled. For example, when checking for updates, the git commands can fail. It would be nice to check for these issues, and at least pretty print them, or something.

When adding or deleting a post, the corresponding element in the cache is deleted, which is correct.

However, we should also invalidate the cache elements for the previous and next posts under certain conditions:

1. when adding a post, the post added just before this one was added should be invalidated, and this post should be invalidated, just in case.
2. When deleting a post, the posts before and after should be invalidated, along with this post.

Ideally the fix for this would be done in conjunction with switching to firing off events when adding/deleting posts.

See https://github.com/jek/blinker. I am still debating the idea of plugins.

If this could be done successfully, it could allow for moving the themes into separate python packages.

Well, when I say all, I am excluding when within a textarea ofc.

Create a setting for the max number of items in the RSS feed.

With pages that display multiple posts, the amount of posts to display on a page is currently hardcoded. This can be made to be configurable as a setting.

Alternatively, it could be made configurable on the page itself, but that seems overly complex IMO, or to put it better, I don't want that feature atm.

Instead of just redirecting to the homepage, we should be using javascript to poll the homepage repeatedly until it comes back up. With some status message saying how many times we have polled or something like that.

This is required for nice auto updates.

I think maybe the GPL v2.

Need to be able to change blog title, theme.

• Create db wrapper that presents settings db table as dict
• Create mapping listing all settings that can be changed
• Add more options to mapping to specify min/max directly there
• Create route and view for displaying settings page
• Create template for settings page
• Handle submission of changed settings
• Upon startup, make sure all settings exist, requesting from command line any that don't
• Change settings usage in rest of web app to use settings dict
• Make sure both templates work
• Remove unnecessary settings in ini files
• Make sure all settings we want in settings webpage are in settings webpage
  • Add fireblog.recaptcha-secret setting
  • Add fireblog.theme setting
  • Add Persona settings
• Remove any redundant code
• Tests...

Keep track of deps, to ensure that any updates to a package don't mess things up. Atm, this isn't done, any version is accepted for (nearly) all packages.

Or at least, call them in a way which doesn't conflict with how uwsgi runs the web app. atm when there are issues with the settings db, uwsgi doesn't let stdout/stdin work for this function.

See https://nextstepwebs.github.io/simplemde-markdown-editor/

Yes, this will slow things down a bit, but it is important.

https://developers.google.com/web/updates/2014/11/Support-for-theme-color-in-Chrome-39-for-Android?hl=en
Can be done as a setting.

Now that I am using uwsgi as the default server, we can't afford to have mismatches due to different worker processes using their own internal caches.

• Set defaults for settings entries, so that there is by default a correct option even if no option is in the db
• Make it so that we can do a git fetch/pull/checkout from within the python code. This will mean that we can get the latest code, check to see if there is a newer version, and switch to it. With all the complexities handled by git.
• Add a view to check for updates by doing a git fetch
  • If there is an update available, say so and check (with alembic) if a db upgrade will be required.
  • If no db upgrade is required, then offer to do the upgrade (ie switch to latest commit), then redirect to the restart view
  • If a db upgrade is required, then print some bash steps to indicate how the upgrade might be done.
  • Add a link to new view to navbar (maybe replacing reload view?)
• Test everything
  • Test git-related code with mocks
  • Test settings default entries code
  • Test view code

A simple way may be to have the code on pypi. Then, whenever a new version is put on pypi, we update and restart.

If possible, having some sort of graceful restart would be really nice, but is not necessary at this point.

See http://docs.pylonsproject.org/projects/pyramid/en/latest/narr/i18n.html

See https://developers.google.com/recaptcha/docs/faq?hl=en#id-like-to-run-automated-tests-with-recaptcha-v2-what-should-i-do

See webhelpers2

Atm, when updating, new packages aren't being installed. Ideally, we would install them in the background first, then once they are installed, we offer the update. Or something like that. I need to think about how to structure the whole process.

title="blah"

The script can be improved to make the initial data better, and we can prompt the user for an initial admin email address

• First of all, a new column is needed in the posts table to keep track of whether a post is a draft or not.
• When editing/adding a post, it should be possible to toggle between draft and published.
• When displaying posts, this new column will need to be checked. Only admin should be able to see draft posts.
• When an admin views a draft post, it should say somewhere on the page that it is a draft post.

When running ìnitialize_fireblog_db, it says at the end to run pserve development.ini. this should be changed to the equivalent uwsgi comnmand.

Running alembic migrations and the initialize_fireblog_db script should be consolidated into one setup process.

By a simple theme, I mean as just raw html. Basically the opposite of what a theme normally would be.

This is unfortunately necessary as it will be discontinued.

Look into adding gravatar support, downloading the images on the server side and directly including them in the Web page.