pageer / lnblog Goto Github PK

We need to add support for a responsive page layout. Right now, viewing a page on a mobile device kind of sucks. We need to fix that.

Some of the changes to the localpath-to-uri logic appear to have broken subdomains. When using the "Automatically list all blogs in sitemap" setting for the SiteMap plugin, all of the blogs that are on their own subdomain just use the current domain as their URL, rather than the correct blog subdomain.

The fix for this is probably to just do away with that function - take all the brains our of it and just make the URL a configuration setting. Maybe make the blog creation do a best-guess at the appropriate URL, but save that as a config and allow it to be manually over-ridden, then just make the config authoritative. There are just too many possibilities and too many cases that the logic gets wrong.

Currently, the "drafts" page just displays a list of draft entries in reverse chronological order with creation, edit, and auto-publish dates below. This makes it hard to see which, if any, entries are up for publication soon. It would be better to have a "publication queue" view that just lists which entries are set to be auto-published, sorted by auto-publish date.

While we're at it, it might also be useful to have a "publication" widget right on the draft page. Maybe something that allows you to view the preview modal and either publish the entry or set the auto-publish date without having to go into the editor.

Right now the subdomain detection logic assumes that the document root for each subdomain lives under a single directory. For example, if SUBDOMAIN_ROOT is /var/www/vhosts, then it would be assumed that foo.example.com would have it's document root at /var/www/vhosts/foo. This is obviously incorrect for many configurations and so inadequate in general.

This should be changed to allow for more configurations. This might mean turning this into an array, allowing regex or glob values, or something else.

Having the session token locked to an IP is a major pain when you're using a laptop and/or a VPN, because you can legitimately change IP addresses any time you sleep the laptop, which end up logging you out. I think it's still worth having this as an option, but it should not be on by default.

It looks like entries that are published by the cron job are not correctly associated with a user. They show up correctly, by the byline is empty. Need to fix that and add code to the upgrade process to correct it (if empty, set post owner to owner of the blog).

The whole "write files over FTP" thing is outdated. No reasonable web host is going to need that anymore. We can keep the underlying mechanism, but it should deprecated and the config step removed from setup.

The controller classes are starting to get really big. We could use an encapsulation for some of this logic.

We'll add a form/command type of system to encapsulate the state handling of web forms (reading and validating fields, repopulating, displaying errors) as well as the action taken on that data. This will better encapsulate individual functions, allow us to potentially reuse the (e.g. via the command line), and hopefully make writing and testing some of the UI-level stuff easier.

It would be nice to allow TinyMCE to be configured without having to modify the plugin. That way people who are so inclined could adjust it to their needs if they don't like the defaults.

In the process of investigating export to WordPress, I discovered that the RSS support is severely lacking. We don't even include dates on the entries, which cause WordPress to mark the entries as created January 1, 1970!

To improve things, we should:

1. Just kill off the RSS1 plugin. I don't think people really use that format anymore anyway.
2. Clean up the RSS2 plugin to make sure it's up to spec.
3. Add in support for Atom feeds, which seem to be the de facto standard these days.

The JavaScript and CSS files should be loaded with cache busting parameters so that browsers will re-request them after an upgrade. Right now, browsers may still use stale cached versions after the system is updated.

If you disable one of the RSS generator plugins, that does not stop the links from showing up in the page. This is because the check is based on the presence of the feed file, which is not deleted when you disable the plugin.

Instead, the check should be based on if the plugin is loaded, so that links will not be displayed if the plugin is off, even if the file is still there.

To complement the WordPress import we added in v2.2, we should also do a WordPress export. That would put the generic export framework in place and give us bi-directional conversion with WordPress.

Some things to consider for this ticket:

• We'll probably have to auto-generate numeric IDs for posts, replies, authors, and pretty much anything else.
• We'll need to generate category and/or tag entries for post tags.
• Should consider if we need to include blog/entry attachments in the export. This will presumably require generating the _wp_attachment_metadata JSON object.

The page to edit paths and URLs stored in blog pathconfig.php files only include the install root path and URL. That file also records the blog root URL, but does not expose a field to edit it. We should also include that, as it may be useful, e.g. if the user moves a blog or re-maps the URL from the web server config.

We currently support displaying and managing uploads on blogs and entries, but not on user profiles. Those allow file uploads as well, so they should also get full file management support.

Right now the old LBCode editor is built right into the entry editing page. This is slightly annoying as it flashes on the screen before TinyMCE takes over. It really doesn't need to be part of the core anyway, since TinyMCE is now the preferred authoring mode.

The LBCode editor should move to a plugin. It should be implemented such that the editor is only ever displayed when the post markup mode is LBCode.

The "delete" link on comments appears to be broken. Clicking it and confirming the in JS prompt results in a "permission denied" message, even for administrators. Note that bulk delete from the "manage replies" page works normally.

The current UI for adding tags to entries is workable, but primitive. We should add a more modern looking JavaScript-basedd tag widget.

For archive and data transfer purposes, we should introduce a site export feature. The idea is to eventually support multiple export formats with the goal of allowing you to keep your data and access it in a meaningful way without having to have a copy of LnBlog installed someplace. Ideally, we would support multiple export formats, including static HTML, more standard XML dialects such as BlogML or Atom, and maybe PDF, but for now, we'll just do static HTML.

The exporter should produce a single file and/or directory that contains all the data for all entries. It should take some display, filtering, and sorting options. For static HTML, this includes:

• Sort order (newest/oldest first).
• Display comments/replies or not.
• Single-file vs. multiple linked files.
  • Multiple should include an index.html to initiate browsing.
  • Both options should produce printer-friendly pages
• Whether to include static articles in the export.
• Whether to generate a contents, index, or other navigation page.
• Filtering by tag.
• Filtering by date range.

Currently, TinyMCE can't deal correctly with image URLs in drafts. A relative URL, which would be correct after publication, can't be resolved in the editor.

The issue is that TinyMCE resolves links relative to the current URL, which is the drafts folder. However, the entry attachments live in a subdirectory of the drafts folder, so the URL that TinyMCE uses isn't valid.

Need to implement some kind of nonce scheme or something similar to better protect against CSRF attacks.

Now that we have a CLI entry point, we should allow upgrading blog wrappers/data from the command line. It's silly to require the user to upgrade each blog through the admin UI, especially if you're already on the server, e.g. to run a git pull. Proposed commands: php ./cli.php --upgrade to do everything or php ./cli.php --upgrade=myblog to upgrade just "myblog".

Note that we need to make sure that user accounts are handled properly for this, because we don't have a "current user" when running from the CLI.

attempted to test LnBlog v2.3.1 in a local environment - after unzipping and the initial configuration page, this...

http://localhost:8081/?action=fssetup

HTTP/1 500 Internal Server Error
Date: Wed, 04 Oct 2023 00:01:22 GMT
Server: Apache/2.4.57 (Unix) PHP/8.2.10

Hello.
I will like to know if u plain to add wordpress support for fully converting from wordpress to LnBlog?
Thank you.

While the version upgrade process isn't too bad, it would be nice if we could completely automate it. This would just download the new version from a well-known location and do the upgrade in one step. Ideally, this would also let you create a backup so you can roll back a bad upgrade.

The upgrade process would do the following:

• Download the archive of the new version.
• (optional) Verify the new version by downloading the checksum and/or GPG signatures and checking that they match.
• (optional) Backup the current version of the software and all blogs it controls.
• Extract the archive.
• Copy over the pathconfig.php.
• Remove the old directory.
• Move the new one to the same path.
• Perform a blog data upgrade if needed.

Initially, this will probably just be a console command. However, we should encapsulate the code in case we want to put a UI around it at any point.

Currently the homepage shows just a fixed number of entries, with no indication that more are present when you reach the end. It's still possible to get to older entries, but you have to go through the archives link in the sidebar. Instead of requiring that, we should have links at the bottom of the page to navigate back and forth through the blog.

We should support modern browser security features. For a start, we should support Content Security Policies (CSP) that disallow inline JavaScript. Currently, there's a bunch of stuff that probably won't work unless you include the unsafe-inline keyword, which is not recommended.

We can do this by either moving all the scripts to external files or supporting a nonce or hash.

The generic file editor page is not loading TinyMCE when it should be. If the plugin is enabled, TinyMCE should replace the text area for files with .html or .html extensions, but this is not happening.

We should have some sort of throttling mechanism to prevent brute-force login attempts. It should log the times of login attempts and lock the account if there are too many failed attempts in a given time period. It should also introduce a delay in processing as the number of failed attempts increases.

We need some sort of password reset or "forgot password" feature. You should be able to enter your e-mail address or username into a page and be sent a link to a reset page with a token that allows you to reset your password.

The current plugin loading screen is a huge pain. Manually entering numbers in the boxes is unacceptable in this day and age. The reordering needs to be drag-and-drop and the disabling should probably be the same way (drag the plugin to a separate list).

The post editor should support uploading things via pasting binary data (e.g. images), like in GitLab.

Ideally, this should upload the file and then insert the appropriate markup into the entry at the current location.

The "display all entries at once" link on the tag listing page doesn't work. It's supposed to show a blog view of a specific tag, with all the entries that have that tag displayed at once. Instead, it just shows the main blog page.

The rich-text editor doesn't play well with some of the semi-HTML config files we have lying around. For instance, the sidebar plugin uses a links.htm that's supposed to be a newline-delimited list of HTML links. However, the rich-text editor mangles that. We should either disable the rich-text editor for that or handle it on the back-end to normalize the output.

We need a simple framework for running asynchronous jobs, i.e. a cron script. The idea is to have an entry point to the application that can run on a schedule or on demand and execute either a specific job or run a queue of pending jobs.

Right now, the handful of third-party JavaScript dependencies is a mish-mash of files checked into the repo and links to CDN scripts. We should manage all that properly. Make the default to pull the dependences from NPM, install them as part of the build process, and maybe make using a CDN an option you can turn on.

This will have the nice side-effect of letting us upgrade TinyMCE, which currently requires an API key if you want to use the latest version from the CDN.

To combat comment span, it would be helpful to have a comment moderation system. Currently, all comments get posted immediately, which can lead to publishing spam.

Initial design thoughts:

• Moderation enabled on a per-entry basis, with defaults settable blog-wide (maybe using the existing plugin that disables comments).
• Comment approval page that lists all comments with moderation pending for all entries.
• Approval page just shows the comments and presents two options: publish or delete.
• When moderation is enabled, flag comments as unmoderated when they are posted. Unmoderated comments are stored like normal comments, but should not display.

The custom link editor for the sidebar doesn't work - it doesn't pass the file name. There are probably some others that don't work too. Also, we need to make sure that the "global" editor links to things in userdata/ work correctly.

We need some kind of feature to automatically insert links, etc. for file attachments to posts. Currently, if you upload an attachment, you have to either type or copy-and-paste the file name into a link or image tag. We should provide a feature to do that automatically.

Note that, to do this correctly, it will need to be markup-dependent and implemented for the following modes:

1. Auto-markup (I'm actually not 100% sure attachments work in this mode currently. We might want to just not allow it for posts, since it's really more for comments.)
2. LBCode
3. Raw HTML (just textarea)
4. HTML using the TinyMCE editor

The highest priority is TinyMCE, since this is (or at least should be) the primary authoring method - it's certainly the most convenient and feature-rich. If other modes have to wait, that's acceptable.

To facilitate upgrades, we should have a simple backup feature. Nothing fancy - just the ability to create an archive of the LnBlog directory and all the blogs it manager. These would probably be ZIP archives - whatever is easiest to create. If we can use a PHP library, that would be great, but falling back to command-line tools should also be allowed if any exotic extensions are needed.

When previewing a post, the markup mode specified in the editor does not seem to be respected. It looks like it's just using what's stored for the draft. To reproduce:

• Create a draft post with LBCode markup mode.
• Open the draft.
• Change the markup mode to HTML. Edit the post so that it's valid HTML (using TinyMCE) with multiple paragraphs.
• Click the preview button

Expected results: The post should display the expected two paragraphs of HTML.
Actual result: The post is all on one line.

hello again Peter

manjaro linux
lnblog 2.3.2
apache 2.4.57
php-apache 8.2.11

several pages are not loading - for ex. i created a new blog and clicked the link in the admin UI to go to it and all was well, and then at some point it wouldn't load anymore

thought this may be a permissions problem, so i ran the tool to fix permissions but that results in an error as well

i'm not well versed in any of this so if you need more info, let me know

i've removed a few redundant lines in the log...

[Mon Oct 09 07:56:21.462799 2023] [mpm_prefork:notice] [pid 3589] AH00163: Apache/2.4.57 (Unix) PHP/8.2.11 configured -- resuming normal operations
[Mon Oct 09 07:56:21.462854 2023] [core:notice] [pid 3589] AH00094: Command line: '/usr/bin/httpd -D FOREGROUND'
[Mon Oct 09 07:57:32.801242 2023] [php:warn] [pid 3593] [client 127.0.0.1:36928] PHP Warning:  Constant FS_PLUGIN already defined in /srv/http/lnblog/lib/AdminPages.php on line 917, referer: http://localhost:8000/lnblog/?action=fssetup
[Mon Oct 09 07:57:32.801440 2023] [php:warn] [pid 3593] [client 127.0.0.1:36928] PHP Warning:  Constant FS_PLUGIN already defined in /srv/http/userdata/fsconfig.php on line 2, referer: http://localhost:8000/lnblog/?action=fssetup
[Mon Oct 09 07:57:32.801446 2023] [php:warn] [pid 3593] [client 127.0.0.1:36928] PHP Warning:  Constant FS_DEFAULT_MODE already defined in /srv/http/userdata/fsconfig.php on line 3, referer: http://localhost:8000/lnblog/?action=fssetup
[Mon Oct 09 07:57:32.801450 2023] [php:warn] [pid 3593] [client 127.0.0.1:36928] PHP Warning:  Constant FS_SCRIPT_MODE already defined in /srv/http/userdata/fsconfig.php on line 4, referer: http://localhost:8000/lnblog/?action=fssetup
[Mon Oct 09 07:57:32.801453 2023] [php:warn] [pid 3593] [client 127.0.0.1:36928] PHP Warning:  Constant FS_DIRECTORY_MODE already defined in /srv/http/userdata/fsconfig.php on line 5, referer: http://localhost:8000/lnblog/?action=fssetup
[Mon Oct 09 08:02:24.747850 2023] [php:warn] [pid 3592] [client 127.0.0.1:58560] PHP Warning:  Undefined variable $PWD in /srv/http/lnblog/themes/default/templates/login_create_tpl.php on line 73, referer: http://localhost:8000/lnblog/index.php?action=index
[Mon Oct 09 08:02:48.608414 2023] [php:warn] [pid 3594] [client 127.0.0.1:43772] PHP Warning:  Undefined variable $PWD in /srv/http/lnblog/themes/default/templates/login_create_tpl.php on line 73, referer: http://localhost:8000/lnblog/
[Mon Oct 09 08:19:37.527991 2023] [php:error] [pid 3590] [client 127.0.0.1:53892] PHP Fatal error:  Uncaught TypeError: readdir(): Argument #1 ($dir_handle) must be of type resource or null, bool given in /srv/http/lnblog/lib/FS.php:332\nStack trace:\n#0 /srv/http/lnblog/lib/FS.php(332): readdir()\n#1 /srv/http/lnblog/lib/Blog.php(1120): FS->scan_directory()\n#2 /srv/http/lnblog/lib/Blog.php(1125): Blog->fixDirectoryPermissions()\n#3 /srv/http/lnblog/lib/AdminPages.php(216): Blog->fixDirectoryPermissions()\n#4 /srv/http/lnblog/lib/AdminPages.php(53): AdminPages->index()\n#5 /srv/http/lnblog/lib/BasePages.php(137): AdminPages->defaultAction()\n#6 /srv/http/lnblog/lib/BasePages.php(66): BasePages->handleRequestRouting()\n#7 /srv/http/lnblog/index.php(5): BasePages->routeRequest()\n#8 {main}\n  thrown in /srv/http/lnblog/lib/FS.php on line 332, referer: http://localhost:8000/lnblog/
[Mon Oct 09 08:31:02.950939 2023] [php:warn] [pid 3624] [client 127.0.0.1:60918] PHP Warning:  opendir(/srv/http/12bytes/entries): Failed to open directory: Permission denied in /srv/http/lnblog/lib/FS.php on line 330, referer: http://localhost:8000/lnblog/
[Mon Oct 09 08:31:02.950996 2023] [php:error] [pid 3624] [client 127.0.0.1:60918] PHP Fatal error:  Uncaught TypeError: readdir(): Argument #1 ($dir_handle) must be of type resource or null, bool given in /srv/http/lnblog/lib/FS.php:332\nStack trace:\n#0 /srv/http/lnblog/lib/FS.php(332): readdir()\n#1 /srv/http/lnblog/lib/Storage/EntryRepository.php(167): FS->scan_directory()\n#2 /srv/http/lnblog/lib/Storage/EntryRepository.php(34): LnBlog\\Storage\\EntryRepository->getEntriesRecursive()\n#3 /srv/http/lnblog/lib/Blog.php(619): LnBlog\\Storage\\EntryRepository->getLimit()\n#4 /srv/http/lnblog/lib/WebPages.php(2146): Blog->getEntries()\n#5 /srv/http/lnblog/lib/WebPages.php(1557): WebPages->getWeblog()\n#6 /srv/http/lnblog/lib/WebPages.php(79): WebPages->showblog()\n#7 /srv/http/lnblog/lib/BasePages.php(137): WebPages->defaultAction()\n#8 /srv/http/lnblog/lib/BasePages.php(66): BasePages->handleRequestRouting()\n#9 /srv/http/lnblog/pages/showblog.php(4): BasePages->routeRequest()\n#10 /srv/http/12bytes/index.php(4): include('...')\n#11 {main}\n  thrown in /srv/http/lnblog/lib/FS.php on line 332, referer: http://localhost:8000/lnblog/

We need a feature to automatically scale on thumbnail images. Without this, it's very inconvenient to upload and post images from a mobile device. I want to be able to just upload pictures from my phone and post them. I shouldn't have to go find aspecial image editor to scale the image.

The post editor could use an auto-save feature. Minimally, it should periodically save the current content of the post area in local storage and offer to restore it in case the browser crashes, the tab is closed, etc. Optimally, it should do an AJAX call to the server and support multiple generations of content, preferably based on whether an edit was additive or not.

We need better scaling quality for the auto-resizing feature for images. Turns out that PHP's imagescale() produces kinda crappy, pixelated results.