Change config.json to config.php

[chrisdavenport]

For obvious security reasons, the API configuration file must not be readable via a simple web request.

[mbabker]

Isn't this repo structured to have all the source code living outside the web root? The presence of the www/ folder and the way the code in the src/ folder reads, that's the intention.

[chrisdavenport]

Yes, that was the original intention, but I think we're going to have problems if we start asking people to install files outside the web root. We need to make it as easy as possible to install and configure.

[mbabker]

Is this designed to be a drop in installable tool like the CMS or an extension? If so, then the approach being taken now won't work for a distributable. If not, then this issue is moot (same with moving the web root thing; because if someone's clever enough to be able to drop that www folder's contents somewhere web accessible on the server with the src folder's contents and config outside the root, they're more than capable of editing the index.php file or whatever is needed to make it work).

[chrisdavenport]

The original thinking was that it would a completely separate distributable, but I'm tending to think that if we want people to actually use this stuff, it needs to be something that can (optionally) be installed using the CMS extension installer and it gets dropped into the same web root as the CMS. Advanced users can then move it wherever they like, tweak the config and it will still work. Or is that not possible?

[mbabker]

My five cents.

If it's being built as a totally separate application not using the CMS application structure (which generally is the case, there's some kind of middle support layer in place for the tie-ins that do exist), then a package that can be installed through the Extension Manager probably is not a desirable goal for this project.

If you're trying to build something similar to WordPress' REST API system which is (from my understanding) native to their application, the architecture here should be more closely aligned to the CMS application structure and less standalone.

As is this seems like it's in a mixed state (part native CMS integration, especially given the presence of the component, and part standalone application). I can't say I know what the right way to go with this is, but I don't think the way things are going right now suggests that you're going to have a package that just easily drops into the CMS as an extension.

[fastslack]

I agree with Chris about this code must to have some easy installer to CMS to give J! a powerful webservices tool but in think that in case that not advanced user install it via Extension Manager, this user do not need to configure another DB only for webservices, so we can use the J! database credentials via original configuration.php. Others parameters (not credentials) can be stored in DB like normal component.

[fastslack]

This is an approach to read default database using backend component:

https://github.com/joomla-projects/webservices/pull/53