Fix spelling of than in comparative + than
Here’s a small patch to fix the spelling of comparative + than, which is currently misspelled as comparative + then in a couple of places.
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.
$ 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" .
$ grep -Ri "notificaiton" .
$
$ 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)
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:
Steps to reproduce:
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
snap logs output from today (while testing this), although the events there do not seem to coincide with the draft problem (just card deletion).
All of my devices are affected by this, or something very similar. My server is running Ubuntu 16.06 with Nextcloud 14.0.1 (in a subdirectory). Here’s logs from my
I trimmed them down to (what appears to me as) the essential, filtered out some noise and replaced my username and the server hostname.
Steps to reproduce:
Replace instruction using ln -s to enable Apache site to use a2ensite instead in Debian and derivatives. Closes #884.
Under Apache Web server configuration, there’s a prompt to create a symlink to enable the newly created site:
ln -s /etc/apache2/sites-available/nextcloud.conf /etc/apache2/sites-enabled/nextcloud.conf
As the instructions in this section are written for Debian, Ubuntu, and their derivatives, a2ensite should be used instead:
a2ensite nextcloud.conf
The commands are currently functionally equivalent (AFAIK), but should this change sometime, the latter would be more future proof, besides being much shorter and easier to type.
Additionally, immediately following the ln -s there is a section about Additional Apache configurations, which correctly instructs the use of a2enmod to create the symlinks. Replacing ln -s with a2ensitewould thus harmonize the two sections.
The plugin refers to $post->post_type before testing it exists, which triggers an error for WP’s built-in (though hidden-by-default since forever) ”link” post type. The error appears quite harmless, as it doesn’t seem to interfere with the link editor’s functionality in any way.
WP_DEBUG on (define as true)add_filter( 'pre_option_link_manager_enabled', '__return_true' );),Links > Add NewSimple Tags’ Settings box in the sidebar shows the following notices:
Notice: Undefined property: stdClass::$post_type in [path to wp]/wp-content/plugins/simple-tags/inc/class.admin.post.php on line 46
Notice: Undefined property: stdClass::$post_type in [path to wp]/wp-content/plugins/simple-tags/inc/class.admin.post.php on line 54