Should I create both www and non-www site aliases for my portals, i.e. www.mydomain.com and mydomain.com?
I currently have both with the www alias defined as the primary and everything works, but I'm wondering what the recommended practice is?
Edit: This is specifically a DotNetNuke configuration question. I understand the difference between the 2 aliases but want to understand whether it is worth using both specifically from a DotNetNuke perspective.
Yes, do both, with a rewrite rule to forward to the one you want to be the canonical one (so you don't miss any statistics).
No, there's no need to do both. I enter whichever one I want to be the primary (usually with the www.). This has worked fine for at least the last 5 years in at least 50 DNN sites I've created and hosted.
Related
I have a website currently running on DNN 3. I want to do an export of this DNN 3 site and import it onto a website running on DNN 9.
Would that be possible?
Anything is possible, maybe, but extremely unlikely that it will be a simple process.
Your best option might be to attempt an upgrade of that DNN3 site to DNN 9.
That or just pay someone to manually recreate the pages and copy/paste content. That might even be the cheapest option :D
Sadly at this point in time this will not be possible, the templates/process for export/import have changed between the versions of DNN and it would not be a trusted or reliable process to do so.
I would second Chris' recommendation regarding just re-create the site, as most likely the modules in use etc are no longer viable.
As Mitchel and Chris already noted, the answer is no. Depending on the size of your site, I would either recreate it from scratch, maybe cou can export/import the content of one or another module and get it up and running in a reasonable time frame.
If the site is really big (and that depends on the number of pages, modules, users,...) it could be better to take some money and hire someone to help. Maybe it is possible to find an upgrade path.
How is it possible to have folder in controller?
For example this scenario: We have multiples clients and each clients might have different package that share the common controller or different controller based on their own request. So I was thinking to separate them by directory in the controller.
Any Expert in Architecture can help this?
This is probably possible, but is certainly not the way you should do things with Cake (or MVC in general, probably).
I suggest that you have a separate app for each client. If you have any specific questions regarding this, or would like to add more information to your question about what you're trying to do, I can try to give you a more in-depth answer.
Without knowing more it is hard to say.
I assume you have one app that is used by multiple clients through subdomains or something else to make a difference between who is using it.
You can have a plugin per client that extends the base apps controllers as needed. You also can have different models and views then. Use routes to make the different named controllers match always the same URLno matter what client is logged in.
I would prefer a one app solution over multiple applications because it reduces the maintenance overhead a lot. But if you want to for multiple apps I would build the core of the application that is shared by all sites as a plugin itself. Using git and submodules you can then even control what version of the core module each site is using.
A site I'm currently managing has Drupal 7.17 on it. I'm noticing the following files in the root of the website:
install.php
CHANGELOG.txt
INSTALL.txt
INSTALL.mysql.txt
INSTALL.pgsql.txt
LICENSE.txt
MAINTAINERS.txt
UPGRADE.txt
Researching this, tells me that as of Drupal 7.16, they fixed a security issue that would allow arbitrary code to run in install.php that would allow the re-installation of Drupal that someone could run. But basically, I am wondering if any of these files (if left in the server root) could cause problems in Drupal 7.17? Do I have to remove these files for security reasons? Or is this no longer a security risk whatsoever in Drupal 7.17?
I understand that we shouldn't remove the upgrade.php file, but just curious on the rest of these files.
Thanks, and this is probably a dumb question, but just felt the need to ask anyways. Usually I remove these files when I install software on websites, but not sure how Drupal uses and/or misuses these files.
Based on the document “Finalize the upgrade” (which applies to both upgrades and installations) from the Drupal handbook:
The last step in an upgrade is to delete or move the following files from your site:
install.php
CHANGELOG.txt
INSTALL.txt
INSTALL.mysql.txt
INSTALL.pgsql.txt
INSTALL.sqlite.txt
LICENSE.txt
MAINTAINERS.txt
UPGRADE.txt
Just to make that clear: the only PHP file to delete is "install.php" (i.e. be sure to leave "upgrade.php" and all other PHP files). And when you delete the TXT files, be sure to keep "robots.txt" since it is used by search engines.
You shouldn't delete any files. If you really wanted to, you could delete various txt files. A better solution if you are afraid of security is to not let the files be accessed through the web server. Drupal only use the index.php file for serving content.
I would love to hear an update and more recent thoughts on this question, and here is why.....
I was just working with a newly updated Drupal site to Drupal 8.9.20 running the Open Social distribution as a logged-in user with no admin privileges. This is my ACTIVE PRODUCTION site!
I deleted a node (News Article) I was trying to embed from a website that refuses to connect on some of their metadata ie: image #1, and after submitting on the delete link, the browser switched to install.php, which as you know sites in the document root.
I was of course shocked to see this and after considering the even innocent response a user might get that lead them to reinstall THEIR App, this could be very dangerous, of course.
So, since the last reply on this references Drupal versions from 2014, I was
just wondering your thoughts in this day and age on what are the latest recommendations!
Thanks
I'm currently in the investigation stage of using CakePHP (2.x in particular). I noticed that on the deployment docs I need to set the document root accordingly in httpd.conf, unfortunately for this project I don't have access to httpd.conf nor any directories below the given webroot.
Given that, my two questions are:
1. Is it possible to still run CakePHP without being able to set the document root?
2. Are there any potential downsides in doing this?
Absolutely, you can use CakePHP in any subdirectory. The only thing you may find useful is the RewriteBase directive, which I think is well explained here: How does RewriteBase work in .htaccess
The one other small problem I've noted is that some CakePHP plugins out there do assume a root directory :( which is unfortunate, and I've had to append Router::url("/") when I see those.
Other than that, you should have no problem running CakePHP on a subdirectory.
I have a website made with CakePHP 1.3.7. This website has it's own login system. Now the client wants to include a forum in the website.
I've been looking at different free solutions and phpBB and SMF seem to be what I'm looking for. The only thing I'm not so sure is about integrating those forums with the login system that I already have.
I mean, if a user has already an account for the website (or creates a new one), he/she should be able to use that same account (username) in the forum section.
Is that possible? Any clue pointing me in the right direction would be much appreciated! I mentioned both forum solutions in case one is easier to integrate than the other one, that would be also good to know (or if there's any other better option).
Thanks so much in advance!
It's possible to use both but I personally prefer SMF. You have to configure CakePHP's session component to use database sessions and create a model that will use the forums session table.
You can decide if you want or need a separate users table besides the forums users table (or its called members, don't know right now).
The "hard" part is to make the cake app read/write the sessions and cookies in the same fashion SMF does to allow a smooth transition from the cake app to the forum and backwards.
Technically you can use both forums and archive your goal with both, it's just a matter of getting the frameworks components utilized right.
I ended up using: this
It has all that I needed and integrates perfectly into Cake :)