Currently I am considering how to better organize the server folder structure of a client.
Mainly for historical reasons, they use different CMS (WordPress, Joomla, ...) as well as custom static coded sites (mainly for online tools).
All these sites get served under same domain:
WordPress based homepage under example.com
Joomla based landingpages under example.com/joomla-lp
Static sites under example-com/static-webtools
Currently this is realized by a quite complex and increasing unmanageable folder structure, where all these different installs find their place within the wordpress folder structure like this:
/var/www/wordpress/ /var/www/wordpress/joomla /var/www/wordpress/webtools
There are plans to further nest systems into each other, let´s say:
/var/www/wordpress/joomla/webtools | example.com/joomla-content/webtools
As all installs are on the same server, hence same IP, I am considering to seperate all these folders in a way like this:
/var/www/wordpress/ /var/www/joomla/ /var/www/webtools/
... and to link specific urls of the same domain to the respective folder.
Any hint, how this can be achieved?
Related
I'd like to build a semi-automated site where pages would be created based on information on the database.
The site would be a vocabulary-like site where there will be thousands of words with their associated meaning, phonetics, and sentence examples along with other useful information.
Since a CMS like WordPress wouldn't work in that sense, what is the best solution for a system like this?
thanks,
Is there a standard way to deploy Umbraco without the backoffice? Some other cmses call this Author / Publish.
I want to configure 2 sites, the public site which does not have a backoffice, and an author site which does have the backoffice. Both of those sites will target the same database, but the author site will only be accessible from within an internal vpn.
The benefit of this approach is security. If there is no backend available on the public site and it is essentially a read only copy of the site it is much harder to hack.
You can deploy the website on one of the servers without the /Umbraco or /Umbraco-client folders which will effectively remove the backoffice. What you're really looking at is a load-balanced scenario. Umbraco 7.3 makes this really easy and there's a fair bit of documentation available.
I would recommend taking a look at the Load Balancing documentation on https://our.umbraco.org/Documentation/Getting-Started/Setup/Server-Setup/Load-Balancing/ - it includes a "recipe" for previous versions along with a good guide on the pitfalls.
I'm looking at some (PHP) Frameworks, and I just noticed this in the Laravel documentation:
Like most web-development frameworks, Laravel is designed to protect your application code, bundles, and local storage by placing only files that are necessarily public in the web server's DocumentRoot. This prevents some types of server misconfiguration from making your code (including database passwords and other configuration data) accessible through the web server. It's best to be safe.
I'm familiar with CodeIgniter and CakePHP, as far as I know, these two frameworks don't do this. Should you really split it up and place your core logic outside of the webroot? In my experience, most clients use shared hosting and are not able to change their VirtualHost settings.
What kind of misconfiguration could you possibly do that would output your passwords? When developing, should you really do this?
Yes, keeping only those files which should be publicly accessible in DocumentRoot is a best practice for web application security. Consider:
Every file which is private would need a rule configured with the web server to explicitly block it.
Anyone adding files to the project needs to consider web server security settings. Simply keeping the files in separate directories makes it obvious what's public. And developers don't need to change security configurations.
Separating executable code and static files is a good practice anyway.
Not blocking access to PHP scripts can cause unintended consequences. For example, you may have a script to update some DB records when run manually at the command line, so someone simply guessing a script name can run it over the internet.
Monitoring for and cleaning malicious code written to the public directory is much easier if the real application logic is elsewhere. See Wordpress breakins for an example.
CakePHP supports this - see deployment:
CakePHP applications should have the document root set to the
application’s app/webroot. This makes the application and
configuration files inaccessible through a URL.
My team has a rather large web application that was built with the Zend Framework, which has become mission-critical to our organization in the past year. It was built as part of an existing ZF corporate web site that no longer meets our needs.
The ZF app has its own users table in a database. It also uses Zend_Acl, and some database tables, to control access to modules, and to individual records. The records largely pertain to people in the system.
Thanks to new business needs, we're now faced with building a new public web site in Joomla. So, we need: (1) to keep running the old system, in some capacity, and (2) a shiny new Joomla site, (3) integration between the two.
-We can't move custody of the users away from our legacy system, because the people those users represent are elemental to the legacy system's purpose.
-We need the usernames and passwords to be the same, and work the same (we have a 60 day reset policy, our usernames aren't fixed values / are a bit convoluted)
-I looked at Zend_Ldap hoping I could expose our users to Joomla that way, but it seems to be just an LDAP client, and I'm not sure implementing an Ldap server in Zend that uses our existing tables is a good use of time. An extension that replaces Joomla's authentication would probably be wiser.
-Can our ACL control Joomla or should we have two ACLs exist in parallel.
-Do we write SOAP services in the Zend app to expose the data to the extension, or do we just give database credentials to the Joomla extensions directly.
A pretty broad question, I know, but I am only looking for broad answers: how would you tackle this?
Thanks!
The first step sounds like integrating the Auth system across Joomla! and your ZF app from there you can direct link to the ZF App's pages for logged in users. I would recommend the use of JFusion to integrate the Joomla! authorisation process and match the ACL groups across the two systems. You will have to write your own plugin for JFusion but that will be very simple compared to porting your entire app to a Joomla! extension. JFusion's GitHub repo is here.
Given the data provided you will need to run the ZF App as the master for authentication and sync user data to Joomla! via your custom plugin.
Once you have your plugin doing the authentication you can use JFusion's direct link mode to link to the ZF App as user that login to Joomla! will be automatically logged into the ZF app (and vice versa).
I have an umbraco installations on one domain: http://www.domain1.com/.
Is there some way (a package or other way) to import the data from this domain (when I say data, I mean the actual content inside the properties in the nodes) into another umbraco installation on a different domain, let's say http:/www.domain2.com/?
(I have, of course user permisiions for both installations).
The reason I am asking is that the first domain is a temporary domain which will hold the data without showing the frontend, while the second domain will hold the final data with the frontend.
Look into the commercial Courier package. It allows you to migrate content in a few clicks. Unfortunately its $99 per domain, but it's way worth it if you have a localhost staging/dev environment that you're migrating content from since it runs from localhost for free. Subdomains are also included in the license.
http://umbraco.com/products/more-add-ons/courier-2.aspx