Skip to main content

This site requires you to update your browser. Your browsing experience maybe affected by not having the most up to date version.

We've moved the forum!

Please use forum.silverstripe.org for any new questions (announcement).
The forum archive will stick around, but will be read only.

You can also use our Slack channel or StackOverflow to ask for help.
Check out our community overview for more options to contribute.

Archive /

Our old forums are still available as a read-only archive.

Moderators: martimiz, Sean, Ed, biapar, Willr, Ingo

Detecting module exists


Go to End


3 Posts   1935 Views

Avatar
Sigurd

Forum Moderator, 628 Posts

8 June 2007 at 11:37am

Some of the code requires knowing if a module has been loaded or not.

For instance, soon the forum module will need to ask

If ( google-mapping-module-installed ) {
google-mapping-module->ShowSomeMap
}

Hayden, can you please add this system?

a) Consult Sam to see about this thinking on it
b) Note that Andrew is working on related code that only loads modules if a _config.php exists See my top post at http://www.silverstripe.com/core-team-discussion/flat/1202/

Avatar
Sam

Administrator, 690 Posts

10 June 2007 at 3:53pm

Simplest solution here is to use class_exists, on the relevant class within that module.

For example:

if(class_exists('GoogleMapField')) {
$fields->addFieldToTab(new GoogleMapField());
} else {
$fields->addFieldToTab(new TextField());
}

Avatar
Ingo

Forum Moderator, 801 Posts

10 June 2007 at 8:01pm

now that we (and external developers) start building modules/plugins, we should think about setting up a basic plugin architecture with hooks into core functionality. some reasons:
- module developers are not dependent on core changes if the right hooks are existing (e.g. to add cmsfields to the standard page-object)
- API changes in module/core don't impact each other heavily
- module developers can release updates independently of the core release cycle
- the core stays cleaner and is easier to debug

we need to think on a broader level here, because we're laying the foundations for future module development. if we just write ad-hoc solutions (hacks?) into sapphire/cms, it just creates more problems on the long run.

matt had some thoughts on this as well, and it might fall in the scope of his GSOC project (mashups).