@eviltrout I got bitten by this in development and didn’t get a warning about setting a key attribute.
Ah, it only warns in Ember.testing
:
We might want to just raise an error if that happens now? It is pretty dangerous for Widgets to do that.
for raising an error instead. Maybe we can extend that to development too?
Hopefully this will prevent others from making this mistake:
https://github.com/discourse/discourse/commit/d4bbdcd7d63ddbf20239c95d1ba1cee9030d7e95
Hi,
Is this url correct? Shouldn’t this be ,
I’m new here. please correct me if im wrong
In Discourse, mainly there are two big JavaScript sections “discourse” and “admin”. Also you can see few more in https://github.com/discourse/discourse/tree/master/app/assets/javascripts.
In plugins, to differentiate admin & normal user section JavaScript files we use “discourse” and “admin” keywords in between like below
plugins/basic-plugin/assets/javascripts/discourse/initializers/alert.js.es6
plugins/basic-plugin/assets/javascripts/admin/initializers/alert.js.es6
Also it will just work even without identification keywords like you mentioned
I’m experiencing the same issue with getting symlinks to work (I’m on Linux) - the ln -s
appears to work, but from inside the docker container the path is inaccessible. The plugin works when it is directly copied into the plugins folder, but I like the symlink workflow as it enables a more sensible Git arrangment.
This SO question appears to suggest that symlinks won’t work this way unless we also add the linked-to plugin volume to the docker run
command Mount host directory with a symbolic link inside in docker container - Stack Overflow
Anyone any thoughts on this? What are the pro plugin developers doing for a sensible Git workflow?
I’m using symlinks but my dev setup is Docker-frei.
Symlinks are a really nice way of being able to include or exclude plugins on a ‘build’ very quickly without disturbing the codebase.
Here’s what I’ve had to do in order to preserve a similar workflow to using symlinks (softlinks):
I edited /bin/docker/boot_dev
in Discourse (outside the container) so that the plugin I want to work on is added as a volume and mounted in the /src/plugins/
directory (inside the container).
In my case it looks like this:
docker run -d -p 9405:9405 -p 1080:1080 -p 3000:3000 -p 9292:9292 \
-v "$DATA_DIR:/shared/postgres_data:delegated" \
-v "$SOURCE_DIR:/src:delegated" \
-v "/home/marcus/code/discourse/discourse-reflective-learning-plugin:/src/plugins/discourse-reflective-learning-plugin" \
$ENV_ARGS --hostname=discourse --name=discourse_dev --restart=always \
discourse/discourse_dev:release /sbin/boot
I’ve used absolute paths because I couldn’t be bothered to get into relative paths inside Docker and $SOURCE_DIR
environment variables, but I’m sure there’s a cleverer way to do this, so that perhaps all your plugins could be in directories at the same level as discourse
and it would automagically include them all. Hope this helps someone.
I am totally open to a PR that automatically follows symlinks in plugins/
dir and then smart mounts volumes.
Hmmmm. That’s a tricky one, because the symlink needed to be deleted, otherwise the Docker mount fails (as it cannot overwrite the existing file).
I had a bit of a google around for solutions, and found an interesting solution which would dereference the symlink and copy the symlink’s target into the specified directory, but couldn’t find anything that would create a Docker volume mount, thus preserving the dynamic link and bi-directional synchronisation. Happy to be steered towards a solution as this would be a neat feature to have.
Tell me how to add your validation to the app/models /user.rb model?
https://github.com/discourse/discourse/blob/8c2e27790cf7c5fcc883489a7bdf36008fda88ac/app/models/user.rb#L99-L110
You can use regular Ruby code to do this in your plugin.rb
:
class ::User < ActiveRecord::Base
validates_presence_of :your_attribute
end
Just starting on my first small plugin I have a few questions I hope someone can help with…
First question is does it matter if we use what’s in this guide or should we really be aiming to use the plugin generator?
It wasn’t covered in this guide, but how can we make data available to our templates from the plugin.rb file?
Let’s say for example I want to display a random welcome message at the plugin-outlet topic-above-posts
whenever somebody visits a topic, with the message being randomly selected from an array in plugin.rb
… how would I send that data to the template? Which I also presume would go here:
plugins/my_new_plugin/assets/javascripts/discourse/templates/connectors/topic-above-posts/my_new_plugin.hbs
(Is this correct?)
Any tips greatly appreciated
Using the plugin generator is generally a great way to get started and see how a plugin should be structured. I recommend it.
Now, regarding how to get ruby code into the front end: those are two different applications. The front end application (Ember) will have to request it from the server (Rails) somehow. Normally we do this via an AJAX call, but you could also do something like add to the SiteSerializer so that it’s sent automatically as part of the forum data.
Otherwise you will have to look up how to add a route/controller in rails and send the messages as JSON.
Thanks Robin!
Would you know if there are any tutorials on this? Or, is there a simple plugin (or even a dummy plugin) we can look at that points us in the right direction? (If not, is this something you could quickly put up for us somewhere please? I think it’ll help a lot of people )
Plus… any more thoughts on writing a book? I can put you in touch with someone if you fancy it
Thanks for the compliment but I’m definitely far too busy to consider writing a book. Plus tech books have SUPER limited range. Those I know who have written them say you do it for yourself, not for the money
I can’t think of simple plugin for returning something from the server side. discourse-tooltips adds a route and then uses that to get previews of topics as you mouseover so that might be helpful.
Soon, I will start plugin development…
Question:
Is there a list of hooks
where we actually can plugin
?
For example, say we want to write a plugin to process the cooked
data in a post
before it is displayed, we would expect there to be at least one hook
at the beginning and one at the end, like (for example):
-
display_post_start
-
display_post_complex
Then, our plugin
would hook
into the code at the hook location
of our choice above.
Is there a list of these plugin hooks
and what are these plugin hooks
called in DiscourseWorld
?
Update: Found this:
git grep "plugin-outlet" -- "*.hbs"
But there was no outlet
for modifying cooked post content, that I can see.
Is there a tutorial on creating our own outlets, for example, an outlet
to modify the cooked
part of posts?
You’re looking for this guide, section decorateCooked()
: