I created a website to replace our current company site using dreamweaver. The website is fully functional when previewed within dreamweaver. I uploaded the files to Network Solutions with no issues. Here is where I believe I messed up...the websites folder name has a space in it. When I attempted to point one of our unused domains to the new website folder "/htdocs/Jeff Jr" the system would not accept the space between Jeff and Jr. I then put it as "/htdocs/JeffJr" and the site isn't showing up.
Is there a character that will read as a space? What should I do?
Generally speaking, you should not use spaces, uppercase characters, or anything other than just text and maybe an underscore here and there. I make the point about uppercase because SEO says it's a bad idea. And it is. Linux systems are case sensative. So it is an issue. And, really the space is particularly dangerous.
The thing is with DreamWeaver is that it's running its stuff locally, and the file system is automatically resolving pathnames. So because the system allows badly formed pathnames, DreamWeaver will work just fine. But you will run into a problem when you move it live.
Related
I had to deactivate a whole bunch of fonts on my computer recently. Thought I had avoided deactivating any system fonts, but I seem to have removed the one that the Adobe Brackets app uses, perhaps even the icon font it uses for sidebar icons?
I'm not sure how this works - if anyone can tell me what fonts this app uses, I can investigate why the interface is not displaying any filenames etc.
It looks like you were hitting this bug with the 'Brackets File Icons' extension. The latest version of the extension should work correctly.
If you want to check whether an extension is a problem, just use Debug > Reload Without Extensions in the menu - no need to muck with the Application Support folder.
Turns out it was a Extensions folder that was causing the issue - may have been a particular plugin, but don't want to point any fingers at this stage. When I uninstalled Brackets (I'm using MacOSX) I had to remove the Brackets folder in Application Support to remove all Extensions as well.
I reinstalled Brackets, put the Brackets folder back into Application support, opened the app, and everything worked fine again.
To see the location of the Brackets Extensions folder, in Brackets go to Help and choose Show Extensions folder.
I have inherited a Drupal 6 site to maintain.
I am new to Drupal so there is an element of learning as I go.
I have encountered a strange issue after attempting to set up a test site on my local machine.
All my links on my local site continue to point to the live server. So all menus, login buttons, etc. all point towards the live site.
Steps I have taken:
checked settings.php to ensure that $base_url is set to "http://localhost:456"
checked settings.php to ensure that MySQL settings are correct
Taken an SQL dump of the entire local database and searched for any references to live site URL
deleted all the local cache data from database
Checked various blocks to ensure that there was no hard coding of links
Disabled language support as that does use separate URLS for each language
I am at a total loss as to where to go from here.
I can navigate through the site locally by replacing the URL in the address bar to point to the local site, and I have even managed to change the local theme so I can see which version of the site I'm on. The fact that I could do this means that the database is set up correctly.
Totally stumped as to where to go from here. Any takers?
The problem was that in the 'variable' table there was an entry with the URL for default language pointing to live site. There is a 'language' table which holds the URLS for each language e.g. eng.example.com for english and ru.example.com for russian. I had changed the urls here to point to local server, but it seems there is also an entry in the variable table which needed to be changed.
In case anybody runs into this problem and wants to change it, you need to change the metadata for the entry as well where S22 represents a string of 22 characters, you need to change it to the length of the string that you are entering, youll see what I mean when you look in the table!
Also, you need to clear your cache after making any change.
In your local server, go to your site directory->site->default and open your settings.php file
look for the base url and comment out that line it should be around line 144
The only thing left is you need to a search for the live site url in your complete code base. See if any module is changing the base url using the code. Though I am not sure how it can be done using code.
However instead of replacing the url you can edit the hosts file and add an entry like
127.0.0.1 livesite.com
If you are using Linux the location of the file is /etc/hosts
I had this problem. I moved the entire site from the remote to the local server to work on, but whenever I loaded the site it went to the live site. I believe the problem was the .htpaccess file. I updated all the core Drupal files, but as the .htpaccess file was hidden I didn't notice it was still there.
Note that even after I removed it, it wasn't until I opened a different site on the local server and then went back that the path worked correctly.
I installed the latest version of Orchard on my dev machine using a base url of localhost/frankgiotto. Then I moved the site to www.frankgiotto.com and updated my Base URL in the settings.
Site works perfectly. I love everything about it but the one thing is that all the links on every page are mapping to www.frankgiotto.com/frankgiotto/etc and I want simply www.frankgiotto.com/etc
This is driving me insane at the moment.. help anyone!?
p.s.. Yes, I made absolutely sure that Base Url is set to www.frankgiotto.com
Interestingly enough, www.frankgiotto.com/Blog and www.frankgiotto.com/frankgiotto/Blog both work and take me to the same place. Its the same with everything else on the site.
This is little out of context, but to make the orchard urls work without any issue on local just do the following
go to Web project
open property->Web
check for "virtual path", set it empty, and all will be fine
that will make the app run without "/", hence less chance for the above issue
Yes, that is a known issue unfortunately. This is because for now links and image addresses are just stored as plain HTML in the database. Ideally, they would be stored as logical references instead and could be rebased on the production server. This feature does not exist today so what we encourage people to do is to use a port rather than a virtual directory on their dev box if they are going to deploy at the root of a domain. This way relative urls just work. In your case I'm afraid you'll have to manually rebase the existing links and change your dev box configuration.
I have a website which google blocked because it had badware i removed the viruses from the server and its completely clean now, the problem that this virus changed in the html, js asp files in the site and added hidden iframes and strange scripts, i removed all what i found in the diles, but the website is toooo big, so any one have any tool which i can use to remove all the effects of this badware?
google gave me this site as a reference to remove the badware from my site
http://www.stopbadware.org/home/security
Thanks,
Wipe everything from the server, check all the files, and re upload them if they're clean. Only thing you can do.
Upload the latest version of the site from your source control DB. If you dont follow source control, its high time you start doing it. ;-)
Find a good search and replace tool. If you are using Dream weaver then you can do a site wide search. The same is applicable to Visual Interdev as well.
+1 William's comment. You can do a simple grep for characteristic strings your particular infection has left behind, such as “<iframe” or the start of the encoded scripts, but you can't be sure to find all the changes that have happened without a manual inspection. This is what having a clean copy on your local computer is for.
i removed the viruses from the server
Really? Are you clean of rootkits? How can you be sure? After an infection, the only sure-fire way to recover a clean server is to reinstall everything on it from the operating system upwards.
Have you discovered and fixed the method the intruders used to get in? If not, you can be sure another of the Russian malware gangs' automated exploits will be back soon enough.
Try soswebscan
scan your website at free of cost with soswebscan.
For more details visit soswebscan website : http://soswebscan.jobandproject.com
I've recently come into a web development position with a company who just lost their server/network admin. Though I was hired for web development, I'm being asked to do some routine maintenance tasks on the server that I'm nonetheless having trouble with, having no background in this sort of stuff. It doesn't help that we've lost all communication with the old network admin.
Here's the situation. A few dozen faculty members in this section of the university have shared directories on the server (Windows Server 2003, SP 2) such as \\servername\Jones$, \\servername\Smith$, and \\servername\Watson$. My question is this: Why are the share names appended with dollar signs? It doesn't appear to be a technical requirement, nor does it distinguish those folders from other similarly-named folders. Is this standard style, a requirement of some sort that I've failed to understand, or something that I should write off as the product of the last admin's eccentricity?
Apologies for the kinda lame question, but I haven't been able to figure this out, and I've been continuing to add new directories with dollar-sign-appended share names because I'm unsure about whether or not it's actually necessary.
The $ in SMB/CIFS URIs means that the share is hidden, and won't be displayed when browsing shared folders. This usually, but not necessarily, implies that it requires administrator privileges to access it.
This convention also applies to shared printers, as well.
Adding a dollar sign ($) to the end of the Share Name will hide the resource from the Network Neighborhood directory. This is referred to as a hidden share.
Appending the dollar sign makes the share hidden, so it won't show up if you browse to the computer in Windows Explorer or use net view on the command line.
If you want to share to show up in those cases, don't put the $ on it.
They are "admin shares" and are usually hidden if you are browsing \computer using windows Explorer or most other browsing tools.
The $ at the end of the share name hides the share from people browsing.
For instance, if you have a share "\computer1\share1$", anyone who browses to "\computer1" will not see share1 listed.
However, if you create the share "\computer1\share2", they will be able to see share2.
That's the only difference I know of.
It's a hidden share. Not only does it not show up, but it's also not searchable.
I know for a fact that in order to access non-shared directories of the target machine, you need to do something like \machinename\c$ where c$ represents the C:\ drive. I am not sure if that is the case in this case.