post i’m testing on
I find that clicking on an existing comment at a tag intersection after clicking on a link does open Docuss, so it would be useable although not functioning as intended. I noticed this last time we talked, so it wasn’t the most recent update, but i felt Docuss was still usable at that point so either the category select was working, or i just missed checking it.
When creating a new thread/discussion a user is required to select their own category, where expected behaviour is that Docuss selects it for them and hides the Category select dropdown box.
Perhaps i was mistaken about the hot-key issue as when creating a new discussion Docuss doesn’t open at all so it wouldn’t be able to auto-select a category. When editing an existing thread ‘alt-a’ does not hide the category dropdown, but i’m not sure that it ever did in the edit window.
Not sure what’s happening here.
I think the first thing to do would be to fix this scary warning in the console:
[PLUGIN dcs-discourse-plugin] Deprecation notice: use injected siteSettings instead of Discourse.SiteSettings (deprecated since Discourse 2.8) (removal in Discourse 2.9)
since the newly installed version of Discourse is… 2.9.
Here is how to do it:
- Replace this line by:
if (!container.lookup('site-settings:main')['docuss_enabled']) {
- In this file, replace the 5 occurences of
Discourse.application.SiteSettings[...] by container.lookup('site-settings:main')[...]
Please let me know if this has any effect.
1 Like
ok, i’ve changed that and rebuilt the app. The error code is gone, but there’s no noticeable difference to the bug.
I also tried with Category Headers switched off as that is also throwing out a whole lot of error codes
Sorry I’m late on this. I will have a look today.
1 Like
@AndyatFocallocal, in this file:
- please replace the 3 occurrences of
model['id'] by model.tag.id
- please replace the single occurrence of
route.get('additionalTags')[0] by model.additionalTags[0]
Let me know how this works.
1 Like
Done that. No changes yet, but probably i have to rebuild the app before it would show. I’ll do that now and test in 10mins.
@syl Ok, not 10mins 
I couldn’t get the app to load with the new code. I’m unsure if it dislikes your changes, or if its something in our setup. Is it possible those changes link to another file and the app is upset they don’t match?
@tmcnulty if you’re online, are you able to see in the server what the reason was it failed to build?
I see this error message:
FAILED
--------------------
Pups::ExecError: cd /var/www/discourse && su discourse -c 'bundle exec rake themes:update assets:precompile' failed with return #<Process::Status: pid 992 exit 1>
Location of failure: /usr/local/lib/ruby/gems/2.7.0/gems/pups-1.1.1/lib/pups/exec_command.rb:117:in `spawn'
exec failed with the params {"cd"=>"$home", "hook"=>"assets_precompile", "cmd"=>["su discourse -c 'bundle exec rake themes:update assets:precompile'"]}
bootstrap failed with exit code 1
** FAILED TO BOOTSTRAP ** please scroll up and look for earlier error messages, there may be more than one.
./discourse-doctor may help diagnose the problem.
54a1af688eb0e62980758ec29397268af27c6dfc3c2c9789ecf3d4df37cbae49
==================== END REBUILD LOG ====================
Failed to rebuild app.
I wonder if this might be the issue:
103:M 04 Jul 2022 13:10:49.304 # WARNING overcommit_memory is set to 0! Background save may fail under low memory condition. To fix this issue add ‘vm.overcommit_memory = 1’ to /etc/sysctl.conf and then reboot or run the command ‘sysctl vm.overcommit_memory=1’ for this to take effect.
Actually, this is a more likely candidate:
130:M 04 Jul 2022 13:10:59.699 # Warning: Could not create server TCP listening socket *:6379: bind: Address already in use
130:M 04 Jul 2022 13:10:59.700 # Failed listening on port 6379 (TCP), aborting.
ok, the command to check worked now. I guess the app had to be running.
/var/discourse$ sudo netstat -tulpn | grep 443
tcp 0 0 0.0.0.0:443 0.0.0.0:* LISTEN 31372/docker-proxy
tcp6 0 0 :::443 :::* LISTEN 31377/docker-proxy
Andy, the changes I requested are in the Discourse plugin, so there should be no need to rebuild the Meteor app. All what’s needed is to commit the changes and then upgrade the plugin using https://publichappinessmovement.com/admin/upgrade.
1 Like
Oh, thanks. Trying that now
Still hitting an issue. Looks like it won’t upgrade Docker manager
Docker Manager: FAILED TO UPGRADE
#<RuntimeError: RuntimeError>
/var/www/discourse/plugins/docker_manager/lib/docker_manager/upgrader.rb:203:in `run'
/var/www/discourse/plugins/docker_manager/lib/docker_manager/upgrader.rb:105:in `upgrade'
/var/www/discourse/plugins/docker_manager/scripts/docker_manager_upgrade.rb:19:in `block in <main>'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/activesupport-7.0.3/lib/active_support/fork_tracker.rb:20:in `block in fork'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/activesupport-7.0.3/lib/active_support/fork_tracker.rb:18:in `fork'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/activesupport-7.0.3/lib/active_support/fork_tracker.rb:18:in `fork'
/var/www/discourse/plugins/docker_manager/scripts/docker_manager_upgrade.rb:6:in `<main>'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/bootsnap-1.12.0/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:39:in `load'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/bootsnap-1.12.0/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:39:in `load'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/railties-7.0.3/lib/rails/commands/runner/runner_command.rb:43:in `perform'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/thor-1.2.1/lib/thor/command.rb:27:in `run'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/thor-1.2.1/lib/thor/invocation.rb:127:in `invoke_command'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/thor-1.2.1/lib/thor.rb:392:in `dispatch'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/railties-7.0.3/lib/rails/command/base.rb:87:in `perform'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/railties-7.0.3/lib/rails/command.rb:48:in `invoke'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/railties-7.0.3/lib/rails/commands.rb:18:in `<main>'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/bootsnap-1.12.0/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:30:in `require'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/bootsnap-1.12.0/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:30:in `require'
bin/rails:18:in `<main>'
Spinning up 1 Unicorn worker(s) that were stopped initially
