PluginsTips - Revision history

Sturm: /* Quickstart */

2020-05-11T03:48:00Z

Quickstart

← Older revision		Revision as of 03:48, 11 May 2020
Line 4:		Line 4:
	#* run it with ./lazyserver.sh so you get debug output (if you run celeryd separately, you won't see logging.info from stuff run in celery tasks)		#* run it with ./lazyserver.sh so you get debug output (if you run celeryd separately, you won't see logging.info from stuff run in celery tasks)
	# <tt>cp -r mediagoblin/plugins/sampleplugin mediagoblin/plugins/myplugin</tt> (where "myplugin" is your plugin name)		# <tt>cp -r mediagoblin/plugins/sampleplugin mediagoblin/plugins/myplugin</tt> (where "myplugin" is your plugin name)
		⚫	# edit <tt>mediagoblin.ini</tt> and add <nowiki>[[mediagoblin.plugins.myplugin]]</nowiki> under the <nowiki>[plugins]</nowiki> section to enable your plugin
	# <tt>cp mediagoblin.ini mediagoblin_local.ini</tt>
⚫	# edit <tt>~~mediagoblin_local~~.ini</tt> and add <nowiki>[[mediagoblin.plugins.myplugin]]</nowiki> under the <nowiki>[plugins]</nowiki> section to enable your plugin

	Now you can look at e.g. other core or non-core plugins for inspiration. See [[Available Plugins]] for non-core plugins.		Now you can look at e.g. other core or non-core plugins for inspiration. See [[Available Plugins]] for non-core plugins.

Unhammer: /* Translating / Localising plugins */

2014-01-26T11:24:42Z

Translating / Localising plugins

← Older revision		Revision as of 11:24, 26 January 2014
Line 59:		Line 59:

	== Translating / Localising plugins ==		== Translating / Localising plugins ==
			''How do we do [[Translations]] in plugins?''
⚫	~~How do we do [[Translations]] in plugins?~~ At least, a plugin would have to install a .mo file in e.g. lib/python2.7/site-packages/pluginname-0.1.3-py2.7.egg/pluginname/i18n/nn_NO/LC_MESSAGES/pluginname.mo (with domain "pluginname"?). Then mediagoblin would have to either discover that the file exists when setting up the plugin, or the plugin would have to add that to some list in some hook.

		⚫	(At least, a plugin would have to install a .mo file in e.g. lib/python2.7/site-packages/pluginname-0.1.3-py2.7.egg/pluginname/i18n/nn_NO/LC_MESSAGES/pluginname.mo (with domain "pluginname"?). Then mediagoblin would have to either discover that the file exists when setting up the plugin, or the plugin would have to add that to some list in some hook.

	mg_globals.py seems to create a gettext variable pointing at mediagoblin/i18n:		mg_globals.py seems to create a gettext variable pointing at mediagoblin/i18n:
Line 79:		Line 81:
	self.template_loader, request.locale)		self.template_loader, request.locale)
	</pre>		</pre>
			)

	== Making database models ==		== Making database models ==

Unhammer: /* Translating / Localising plugins */

2014-01-26T11:24:15Z

Translating / Localising plugins

← Older revision		Revision as of 11:24, 26 January 2014
Line 79:		Line 79:
	self.template_loader, request.locale)		self.template_loader, request.locale)
	</pre>		</pre>

			== Making database models ==
			See [[SQLAlchemy Tips]]

Unhammer: /* Translating / Localising plugins */

2014-01-20T14:50:02Z

Translating / Localising plugins

← Older revision		Revision as of 14:50, 20 January 2014
Line 59:		Line 59:

	== Translating / Localising plugins ==		== Translating / Localising plugins ==
	How do we do ~~this~~? At least, a plugin would have to install a .mo file in e.g. lib/python2.7/site-packages/pluginname-0.1.3-py2.7.egg/pluginname/i18n/nn_NO/LC_MESSAGES/pluginname.mo (with domain "pluginname"?). Then mediagoblin would have to either discover that the file exists when setting up the plugin, or the plugin would have to add that to some list in some hook.		How do we do [[Translations]] in plugins? At least, a plugin would have to install a .mo file in e.g. lib/python2.7/site-packages/pluginname-0.1.3-py2.7.egg/pluginname/i18n/nn_NO/LC_MESSAGES/pluginname.mo (with domain "pluginname"?). Then mediagoblin would have to either discover that the file exists when setting up the plugin, or the plugin would have to add that to some list in some hook.

	mg_globals.py seems to create a gettext variable pointing at mediagoblin/i18n:		mg_globals.py seems to create a gettext variable pointing at mediagoblin/i18n:

Unhammer: /* Translating / Localising plugins */

2014-01-20T13:44:58Z

Translating / Localising plugins

← Older revision		Revision as of 13:44, 20 January 2014
Line 59:		Line 59:

	== Translating / Localising plugins ==		== Translating / Localising plugins ==
			How do we do this? At least, a plugin would have to install a .mo file in e.g. lib/python2.7/site-packages/pluginname-0.1.3-py2.7.egg/pluginname/i18n/nn_NO/LC_MESSAGES/pluginname.mo (with domain "pluginname"?). Then mediagoblin would have to either discover that the file exists when setting up the plugin, or the plugin would have to add that to some list in some hook.
	: How do we do this?

			mg_globals.py seems to create a gettext variable pointing at mediagoblin/i18n:
			<pre>
			thread_scope.translations = gettext.translation(
			'mediagoblin',
			pkg_resources.resource_filename(
			'mediagoblin', 'i18n'), ['en'], fallback=True)
			</pre>
			which is installed into the jinja template in template.py:
			<pre>
			template_env.install_gettext_callables(
			mg_globals.thread_scope.translations.ugettext,
			mg_globals.thread_scope.translations.ungettext)
			</pre>
			in a function called by app.py:
			<pre>
			request.template_env = template.get_jinja_env(
			self.template_loader, request.locale)
			</pre>

Unhammer: /* Referencing the mediagoblin test set in a plugin */

2014-01-20T13:16:19Z

Referencing the mediagoblin test set in a plugin

← Older revision		Revision as of 13:16, 20 January 2014
Line 57:		Line 57:

	See also [http://mediagoblin.readthedocs.org/en/latest/pluginwriter/tests.html Writing unit tests for plugins] in the docs.		See also [http://mediagoblin.readthedocs.org/en/latest/pluginwriter/tests.html Writing unit tests for plugins] in the docs.

			== Translating / Localising plugins ==
			: How do we do this?

Unhammer: /* Referencing the mediagoblin test set in a plugin */

2014-01-19T12:09:22Z

Referencing the mediagoblin test set in a plugin

← Older revision		Revision as of 12:09, 19 January 2014
Line 54:		Line 54:

	An example of this test method is in the [https://gitorious.org/mediagoblin-stock/mediagoblin-hidden_original/ "hidden original" plugin], which subclasses the submission tests.		An example of this test method is in the [https://gitorious.org/mediagoblin-stock/mediagoblin-hidden_original/ "hidden original" plugin], which subclasses the submission tests.


			See also [http://mediagoblin.readthedocs.org/en/latest/pluginwriter/tests.html Writing unit tests for plugins] in the docs.

Unhammer: /* Referencing the mediagoblin test set in a plugin */

2014-01-17T19:57:45Z

Referencing the mediagoblin test set in a plugin

← Older revision		Revision as of 19:57, 17 January 2014
Line 51:		Line 51:
	In fact, the only files you need are `conftest.py` and `pytest.ini`, and then you can copy over a single `test_foo.py` (only making sure import statements are absolute) and it should run fine.		In fact, the only files you need are `conftest.py` and `pytest.ini`, and then you can copy over a single `test_foo.py` (only making sure import statements are absolute) and it should run fine.

	You also need to call setup_plugins() in your setup function for your plugin to be properly loaded before testing.		You also need to call setup_plugins() in your setup() function for your plugin to be properly loaded before testing.

			An example of this test method is in the [https://gitorious.org/mediagoblin-stock/mediagoblin-hidden_original/ "hidden original" plugin], which subclasses the submission tests.

Unhammer: /* Making an installable plugin */

2014-01-17T19:56:10Z

Making an installable plugin

← Older revision		Revision as of 19:56, 17 January 2014
Line 36:		Line 36:

	The setup.py file defines an option include_package_data=True, which makes it read the file MANIFEST.in; MANIFEST.in contains rules for which files to include when installing. In this case, rule <tt>recursive-include mediagoblin_rdfa *.html</tt> makes it include the HTML template file (and any other you put under mediagoblin_rdfa), retaining the folder layout.		The setup.py file defines an option include_package_data=True, which makes it read the file MANIFEST.in; MANIFEST.in contains rules for which files to include when installing. In this case, rule <tt>recursive-include mediagoblin_rdfa *.html</tt> makes it include the HTML template file (and any other you put under mediagoblin_rdfa), retaining the folder layout.

			==Referencing the mediagoblin test set in a plugin==

			The tests in mediagoblin define a nice "test_app" and functions for logging in and posting and so on. You can use this in your installable plugin.

			From your plugin (assuming a layout like mg-rdfa described above), doing

			cp -r ../mediagoblin/mediagoblin/tests .

			lets you run

			../mediagoblin/bin/py.test tests --boxed

			In fact, the only files you need are `conftest.py` and `pytest.ini`, and then you can copy over a single `test_foo.py` (only making sure import statements are absolute) and it should run fine.

			You also need to call setup_plugins() in your setup function for your plugin to be properly loaded before testing.

Unhammer: /* Quickstart */

2014-01-17T19:53:22Z

Quickstart

← Older revision		Revision as of 19:53, 17 January 2014
Line 8:		Line 8:

	Now you can look at e.g. other core or non-core plugins for inspiration. See [[Available Plugins]] for non-core plugins.		Now you can look at e.g. other core or non-core plugins for inspiration. See [[Available Plugins]] for non-core plugins.


			The way you change things in plugins is by use of '''hooks'''. At certain points in the mediagoblin code, a function will say "run all hooks with name XYZ", and if you've defined a hook with such a name in a plugin you've enabled, it'll get run there. The [http://mediagoblin.readthedocs.org/en/latest/pluginwriter/api.html documentation on Plugin API] is your friend for defining hooks. The sample plugin shows a use of the 'setup' hook.

			Note: templates are hooked with a call to pluginapi.register_template_hooks, instead of adding to the hooks variable.

	==Making an installable plugin==		==Making an installable plugin==