With WP_DEBUG enabled, a non-existing page (404) logs the following PHP error:
Trying to get property of non-object in wp-content/themes/cover2/components/header/header-overlay.php on line 53
I believe this is caused by the $post reference on that line, as $post has not been populated on a 404 page.
After upgrading to Quantum, the right mouse button context menu for HTML links pops up in the wrong place when the Firefox window is pushed to either side of my screen (so that the window takes up half of the horizontal space). The issue appears similar to what has been reported in bug #1721614 (particularly as it appears in the video attached by the submitter), but for me the issue does not occur with the hamburger menu or other UI elements, only with links on webpages, and the menu highlighting behavior is different: in my issue the highlighting occurs normally only once I point the cursor at the menu.
== Steps to reproduce ==
1. Create a new profile and start Firefox using the profile.
2. Expand the window to fill the screen (if not already).
3. Enter search terms into the URL bar and hit enter to bring up a search results page.
4. Right-click a search result title to bring up the context menu. Left-click outside it to close it.
5. Grab the window title bar and push the window to the right edge of screen to resize the window to span half of screen horizontally. Release the title bar.
4. Right click the search result title again.
== What happens ==
The menu pops up on way off from where the mouse cursor is. See attached screenshot.
== What should happen ==
The context menu should pop up next to mouse cursor.
== Possible culprit ==
This seems to be somehow tied to localization: if I uninstall firefox-locale-*, then create a new Firefox profile, with this new profile the menu pops up where it should. I’m using Finnish locale, but this is reproducible with just firefox-local-en too, although the mispositioning differs between locales (Finnish pushes the menu off to the left, whereas English pushes it down and to the right).
== Workaround ==
Don’t right-click on the page before resizing the window (that is, skip step #4 above). This seems to be the trigger.
== Other info ==
I’m able reproduce this in a (16.04) VM just as well as on the host desktop.
In case the collected data doesn’t include this, my primary display is 2560 × 1440p, and the only display connected. xrandr output:
Screen 0: minimum 320 x 200, current 2560 x 1440, maximum 8192 x 8192
VGA-1 disconnected (normal left inverted right x axis y axis)
HDMI-1 disconnected (normal left inverted right x axis y axis)
DP-1 connected primary 2560×1440+0+0 (normal left inverted right x axis y axis) 527mm x 296mm
2560×1440 59.95*+
2048×1152 59.90
1920×1200 59.88
1920×1080 60.00 50.00 59.94 24.00 23.98
1920x1080i 60.00 50.00 59.94
1600×1200 60.00
1680×1050 59.95
1280×1024 75.02 60.02
1280×800 59.81
1152×864 75.00
1280×720 60.00 50.00 59.94
1024×768 75.03 60.00
800×600 75.00 60.32
720×576 50.00
720×480 60.00 59.94
640×480 75.00 60.00 59.94
720×400 70.08
HDMI-2 disconnected (normal left inverted right x axis y axis)
HDMI-3 disconnected (normal left inverted right x axis y axis)
DP-2 disconnected (normal left inverted right x axis y axis)
DP-3 disconnected (normal left inverted right x axis y axis)
Screenshot with the context menu off to the left of mouse cursor (Finnish locale) Edit (490.3 KiB, image/png)
V0.55 didn’t fix this unfortunately: my steps to reproduce still produce the unstylized text and not a code block.
tracking: stable
installed: 0.55 (87) 125MB –
refreshed: 2017-11-19 19:51:40 +0200 EET
Perak’s markdown ironically has had one issue reported about a reverse problem: someone had their first line always treated as code block (which was because they had indented the line). No bugs reported about the first line indentation being trimmed off.
@droidmonkey That page seems to have been deleted from the wiki, but I think I found the problem, sort of. I’m using the -proposed repository, where the current proposed snapd-xdg-open (2.28.5) is just a transitional package (pointing back to snapd), as they’ve integrated xdg-open into snapd itself.
If I downgrade snapd-xdg-open back to 0.0.0~16.04 from -updates (which also requires a downgrade of snapd back to 2.27.5), the Open URL function in KeepassXC does work (with the fresh 2.2.2 release at least).
So an upcoming change in these packages will break this, unless they do some more juggling before the packages move from -proposed to -updates.
The issue persists for me in 2.2.1 in Ubuntu 16.04. I can get it to work by removing snad-xdg-open from snapcraft.yaml (effectively reverting PR #1011) before building the snap.
Reproducible here on a Galaxy Tab 4 (SM-T530), Android 5.0.2.
@xet7 Ah yes, the backticks are a cleaner workaround.
Not sure what you meant about the description supporting markdown, as markdown formatting of the description is what I was reporting on :)
In case my wording was unclear, I didn’t mean I wanted to preserve the indentation going from the editor to the formatted view, but to use markdown’s indented code block feature, which works just fine unless the indentation occurs right at the beginning of the description (or a comment), where the starting indention is trimmed off (thus breaking the code block formatting).
Impacted version: 0.49
Server Setup Information:
Steps to reproduce:
first line
second line
What happens:
The description is plain, unstylized text.
What I expect to happen:
For the description to be rendered as a code block.
How to work around this:
I have to enter at least one non-whitespace character followed by at least two newlines before entering the indented code block. Urgh :(
Impacted version: 0.49
Server Setup Information:
Steps to reproduce:
What happens:
The description field still shows ”You have an unsaved description” with the just saved description text. The only way to make the warning go away is to select the ”Discard” link.
What I expect to happen:
I’d expect the ”You have an unsaved description” notice to disappear when the description is saved.
Impacted version: 0.39
Server Setup Information:
Steps to reproduce:
What I expect to happen:
For the board to be imported in Wekan.
What happens:
The importer reports a ’400’. journalctl -u snap.wekan.wekan.service reports
Exception while invoking method 'importBoard' Error: Card id is required
at getErrorObject (packages/aldeed_collection2-core.js:480:15)
at [object Object].doValidate (packages/aldeed_collection2-core.js:462:13)
at [object Object].Mongo.Collection.(anonymous function) [as insert] (packages/aldeed_collection2-core.js:214:25)
at packages/matb33_collection-hooks.js:127:46
at [object Object]._.extend.withValue (packages/meteor.js:1122:17)
at Object.directOp (packages/matb33_collection-hooks.js:47:27)
at Object.self.direct.(anonymous function) [as insert] (packages/matb33_collection-hooks.js:126:30)
at models/trelloCreator.js:408:45
at Array.forEach (native)
at TrelloCreator.createChecklists (models/trelloCreator.js:400:22)
at TrelloCreator.create (models/trelloCreator.js:608:10)
at [object Object].Meteor.methods.importBoard (models/import.js:27:20)
at packages/check.js:130:16
at [object Object]._.extend.withValue (packages/meteor.js:1122:17)
at Object.exports.Match._failIfArgumentsAreNotAllChecked (packages/check.js:129:41)
at maybeAuditArgumentChecks (packages/ddp-server/livedata_server.js:1734:18)
Sanitized and reported to the client as: Card id is required [400]
I’m attaching the failing JSON.
To be fair, I think the blame here mostly lies with Trello: it does not preserve archived lists when copying a board (you won’t find them from archived lists view in the copy), but for some reason it does carry the checklists contained in those lists over, and they then pop up in the export file.
Wekan’s ”Card id is required” error is slightly misleading here though: I think the problem isn’t a missing card ID, but the fact that the parent card referenced by the checklist does not come with the export.