My test blog is running WP 5.0-beta3-43867 with Gutenberg 4.3.0-alpha-0841246 (from Daniel Bachhuber’s nightly), and the theme I’m using is Cover2 (Github here), which also appears to exhibit this in single post view.
I’ve narrowed it down to this function (called from header.php), where the gutenberg_parse_blocks()
call triggers the issue.
I’m not saying I’m 100 % sure it’s Gutenberg and not the theme(s) at fault here, but I just thought I’d post this just in case it helps to find out either way.
Amended to replace whitespaces mixed with tabs in extension.json, and to fix description message id.
Refactor file structure so that the extension can be loaded using MW 1.25+ style wfLoadExtension()
, and makes MW 1.25+ a requirement. Otherwise the core functionality should remain just as it was (i.e., if it doesn’t, that’s unintentional on my part).
This closes issue #3.
Since MediaWiki 1.25, the suggested method of registering extensions has been to use wfLoadExtension()
instead of a direct require_once
. AddBodyClass currently (v1.2.0 from 2016-03-21) still uses the old style, so I’m opening this issue to suggest converting the extension to use the new method.
I’m also preparing a pull request with the minimal changes that I think should accomplish this, and I’ll post it next.
Here’s a small patch to fix the spelling of comparative + than, which is currently misspelled as comparative + then in a couple of places.
Not sure if this URL is supported, but the error message doesn’t look quite right, nor clear as to what the problem is from a user’s perspective:
$ yle-dl 'https://yle.fi/aihe/artikkeli/2013/04/11/aanien-illoissa-kuunnellaan-kadonneitakin-aania'
yle-dl 2.37: Download media files from Yle Areena and Elävä Arkisto
Copyright (C) 2009-2018 Antti Ajanki <antti.ajanki@iki.fi>, license: GPLv3
Traceback (most recent call last):
File "/usr/local/bin/yle-dl", line 11, in <module>
load_entry_point('yle-dl==2.37', 'console_scripts', 'yle-dl')()
File "build/bdist.linux-x86_64/egg/yledl/yledl.py", line 377, in main
File "build/bdist.linux-x86_64/egg/yledl/yledl.py", line 252, in download
File "build/bdist.linux-x86_64/egg/yledl/extractors.py", line 543, in extract
File "build/bdist.linux-x86_64/egg/yledl/extractors.py", line 736, in extract_clip
File "build/bdist.linux-x86_64/egg/yledl/extractors.py", line 983, in program_info_for_pid
File "build/bdist.linux-x86_64/egg/yledl/extractors.py", line 791, in media_flavors
File "build/bdist.linux-x86_64/egg/yledl/extractors.py", line 875, in download_flavors
File "build/bdist.linux-x86_64/egg/yledl/backends.py", line 499, in __init__
File "build/bdist.linux-x86_64/egg/yledl/backends.py", line 40, in __init__
AttributeError: 'NoneType' object has no attribute 'startswith'
I made a note about the failure in my kanban (yesterday) at ”13:17:10 GMT+0300 (EEST)”, so that would have been 10:17:10 UTC.
The build-android
target calls the pre-build
target as pre-buid
, resulting in build failure for the build-android
target. This PR fixes the issue.
(PR #2272 did the same for a typo in the build-pr
target.)
The push proxy codebase refers to notifications as ”notificaitons” once in the README and once in a LogInfo()
call.
Steps to reproduce
$ git clone https://github.com/mattermost/mattermost-push-proxy.git
$ cd mattermost-push-proxy/
$ git rev-parse HEAD
41affc6595fc927a75de1184292cec89278b40a8
nothing to commit, working tree clean
$ git rev-parse HEAD
41affc6595fc927a75de1184292cec89278b40a8
$ grep -Ri "notificaiton" .
Expected behavior
$ grep -Ri "notificaiton" .
$
Observed behavior (that appears unintentional)
$ grep -Ri "notificaiton" .
./server/android_notification_server.go: LogInfo(fmt.Sprintf("Initializing Android notificaiton server for type=%v", me.AndroidPushSettings.Type))
./README.md:For more in-depth instructions on setting up push notificaitons with your own build please follow the directions at [docs.mattermost.com](https://docs.mattermost.com/developer/mobile-developer-setup.html#push-notifications-with-your-own-build)
Possible fixes
Here’s a link to the line in server/android_notification_server.go
, README.md link unavailable because Github doesn’t allow per-line linking to Markdown files (that I know of). I think this should be pretty easy to fix and I can provide a pull request.
Server Setup Information:
- Wekan version: 1.53
- Deployment Method: snap (tracking stable)
- Operating System: Ubuntu 16.04
- Http frontend: Apache 2.4
- ROOT_URL environment variable https://my-domain.com/kan
Screen recording:
Steps to reproduce:
- Create a card
- Click on the comment field, enter ”some text”
- Click on the description field
- Close the card
- Open the card
- Try to delete the ”some text” comment draft, either by selecting and clearing out the text, or by posting the comment (by selecting ’Comment’)
- Close the card, open it again
What happens:
The comment draft remains in the comment field. If you posted it at step 6 above, you now have the posted comment plus the same comment as draft.
What I expect to happen:
For the comment draft to have been deleted. If you skip step 3 (i.e. don’t click on the description field but close the card directly), the draft is deleted. While I’d actually prefer the draft to remain in this situation, this is slightly better than the undeleteable draft.
Web Console contents:
Upon closing the card at step 4, console shows this:
remove failed: Internal server error 9f30bda751070caba2631cd997a9c88102b36537.js:1:6261
insert failed: i@https://my-domain.com/kan/9f30bda751070caba2631cd997a9c88102b36537.js?meteor_js_resource=true:89:2640
t@https://my-domain.com/kan/9f30bda751070caba2631cd997a9c88102b36537.js?meteor_js_resource=true:89:2478
c.Collection.prototype[i]@https://my-domain.com/kan/9f30bda751070caba2631cd997a9c88102b36537.js?meteor_js_resource=true:89:6720
@https://my-domain.com/kan/9f30bda751070caba2631cd997a9c88102b36537.js?meteor_js_resource=true:111:4415
n/</i[n]@https://my-domain.com/kan/9f30bda751070caba2631cd997a9c88102b36537.js?meteor_js_resource=true:111:1717
set@https://my-domain.com/kan/9f30bda751070caba2631cd997a9c88102b36537.js?meteor_js_resource=true:299:385103
t@https://my-domain.com/kan/9f30bda751070caba2631cd997a9c88102b36537.js?meteor_js_resource=true:299:165991
inlinedform.js/<@https://my-domain.com/kan/9f30bda751070caba2631cd997a9c88102b36537.js?meteor_js_resource=true:299:375381
9f30bda751070caba2631cd997a9c88102b36537.js:1:6261
Other info
- I’d rate this Severity:Inconvenient
- There is at least one way to delete the draft: after clearing out the text, click the description field, then close the card. This again results in the above errors being reported in the console, but opening the card reveals that the draft is now gone.
- This is slightly reminiscient of issue #1287 (also reported by me way back when), though my guess would be that these are completely unrelated, and I’m only making the link here just in case the solutions happen to be similar (as both deal with drafts and saving).
- I’m attaching
snap logs
output from today (while testing this), although the events there do not seem to coincide with the draft problem (just card deletion).