@eviltrout I got bitten by this in development and didn’t get a warning about setting a key attribute.
Ah, it only warns in
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:
Is this url correct? Shouldn’t this be ,
I’m new here. please correct me if im wrong
Also it will just work even without identification keywords like you mentioned
@vinothkannans Thank you a lot for the explanation.
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):
/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?
You can use regular Ruby code to do this in your
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:
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.
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…
Is there a list of
hooks where we actually can
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):
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
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