Generally, when I open the source page, basic thing when I see on my CSS or JS link rel is like below:
<link rel="stylesheet/less" type="text/css" href="http://blog.zakariyasoewardi.co.uk/wp-content/themes/wordpress-bootstrap/less/bootstrap.less">
I use third party plugin who claim can make nobody know I use WP, I'm sure my link rel will be like below if I setting with that:
<link rel="stylesheet/less" type="text/css" href="http://blog.zakariyasoewardi.co.uk/node/1/wordpress-bootstrap/less/bootstrap.less">
But in specific case, I need hack URL link rel much easier when people or I shot the source page, this is what I mean:
<link rel="stylesheet/less" type="text/css" href="/wordpress-bootstrap/less/bootstrap.less">
Is it possible?
I believe several developer can, I notice few of Website where I included in their service as member does well.
There are already answers for what you want to do:
https://stackoverflow.com/search?q=hide+wordpress
and
https://wordpress.stackexchange.com/search?q=hide+wordpress
and on the web in general
http://www.google.com/search?q=hide+wordpress
That said, this is called security through obscurity, which really isn't security at all. Bots will still find the fact that you are using WordPress. Casual viewers of browser source will, too. You're basically wasting your time.
You're much better off leaving all that alone and reading http://codex.wordpress.org/Hardening_WordPress and being sure you're on a good, secure web host.
WordPress isn't necessarily or chronically insecure (though, like any software package, vulnerabilities keep popping up). The main issue is that WordPress is very popular - 50 million sites and counting, they say, at the time of this post - and that makes it a target in terms of lots of insecure themes, plugins and sketchy hosts that cater to the WordPress ecosystem. And that means lots of targets in terms of millions of sites that may be mis-configured in terms of security.
Related
My site is handwritten to be lightweight in amp. It has two language alternatives, en and tr.
barakudabodrum.com/tr/ is in Turkish and should be targeting users in Turkey.
barakudabodrum.com is in English and should be targeting the rest of the world.
I am using rel="alternate" tags inside each webpage and not in sitemap.
My questions are not about SEO. At this moment I just want to setup correctly.
Should I create two properties for each language inside search console?
Should I have two sitemaps and two sitemap indexes?
Should I also mention about them inside robots.txt?
I found information pieces everywhere but not a complete guidance on different ways of international targeting.
Thanks
You mention that your question "is not about SEO", however, most of what you have asked does not make sense outside the context of SEO. The entire point of setting up something like an hreflang tag is to avoid algorithmic penalties for duplicate content and to optimize your organic traffic in terms of international SEO.
If you are not concerned about SEO, you don't have to worry about any of the questions you mentioned. If on the other hand, your questions are entirely about SEO, then here is what you should keep in mind.
From a Google Search Console point of view, you'll likely want to keep everything under a single account, as you have opted to use a single domain. If, on the other hand, you had opted for two ccTLDs, then you'd want to break things out under two separate Search Console accounts.
Looking at the way you have set up your hreflang tags, there seem to be some issues.
Take for example the tags from the following page:
http://barakudabodrum.com/en/diving
<link hreflang="x-default" href="http://barakudabodrum.com/dalis" rel="alternate">
<link hreflang="tr" href="http://barakudabodrum.com/tr/dalis" rel="alternate">
<link hreflang="en" href="http://barakudabodrum.com/en/diving" rel="alternate">
In the first tag, you have the hreflang set to "x-default", which is not a language code. At the end of this tag you have listed rel="alternate", an hreflang tag can have a rel attribute of either x-default or alternate, it cannot be both.
The best practices, for maximizing international SEO state that you should ideally have a sitemap for every language you target, as well as one for each country. Which leads me to a follow-up question, which is why you are not using country codes inside your hreflang tags.
If you where targeting only people in Turkey, who spoke either English or Turkish, you would use:
<link hreflang="tr-tr" href="http://barakudabodrum.com/tr/dalis" rel="x-default">
<link hreflang="en-tr" href="http://barakudabodrum.com/en/diving" rel="alternate">
If alternatively, you were targeting only English speakers from the United States and Turkish speakers from Turkey, then it would be:
<link hreflang="tr-tr" href="http://barakudabodrum.com/tr/dalis" rel="x-default">
<link hreflang="en-us" href="http://barakudabodrum.com/en/diving" rel="alternate">
A Google font we use (Pacifico) recently had a rather radical redesign to the capital 'L'. As we use this for our product with a name begging with 'L' this caused a rather radical change in the look to our product.
Digging into it, I noticed that the url for the fonts had changed from
fonts.gstatic.com/s/pacifico/v7/Q_Z9mv4hySLTMoMjnk_rCXYhjbSpvc47ee6xR_80Hnw.woff2
to
fonts.gstatic.com/s/pacifico/v8/Q_Z9mv4hySLTMoMjnk_rCXYhjbSpvc47ee6xR_80Hnw.woff2
but that the previous v7 urls still worked. So, for now, I have added hardcoded font references to that version.
Is it possible, though, to instead link to a particular version of a font?
<link href='https://fonts.googleapis.com/css?family=Pacifico' rel='stylesheet' type='text/css'>
So, somehow specify a version in the above link?
I have tried various guesses, such as:
https://fonts.googleapis.com/css?family=Pacifico&version=7
https://fonts.googleapis.com/css?family=Pacifico&version=v7
https://fonts.googleapis.com/css?family=Pacifico:v7
but to no avail.
The recommended way to stick with a particular version is to self-host it.
Google does not and will not have a versioning option.
The API v7 hack you're using is officially not recommended, and may break.
A Google Fonts employee “davelab6” has been responding to several questions like yours on the Google Fonts github. This question is much like yours and has a brief answer from him. It also links to several other issues with spirited discussion about a similar change.
The upshot is that Google has considered offering a versioning feature and rejected it for several reasons. They say the vast majority of users will be fine with the latest version of a font, and the rest can self-host the version they like.
As for how to self-host, I'm out of my depth, but there's a question about it here with several answers.
I am a newbie in Web designing. I learnt about templates that are available online that people can purchase and change the content according to their requirements.
One thing puzzled me. Why do people purchase themes when they can copy the code using VIEW SOURCE option. I have tried searching the answer but google has failed me.
Also, If I am not using Wordpress, can still I use Wordpress themes for my website.
Thanks!!
Because, while often technologically possible, that's still copyright infringement.
Because WordPress themes usually are more than just their raw HTML/CSS/JS. The PHP logic is frequently pretty complex and important.
1.) Copying source code is stealing. If you're copying the html/css, you'll probably copy the images, too. Definitely could be legal issues in that.
2.) If you decide to try and steal it anyways, you'll notice in a lot of cases they've used Iframes or JavaScript to pull the code in from elsewhere, where you do not have access to it.
3.) Copying CSS and HTML wouldn't do much for a Wordpress site. You wont' be able to copy any of the server-side stuff.
4.) You can't really use the theme because a Wordpress theme comes with functions and much more. You could use the CSS with a lot of hacking.
We can only copy the Html form either full encoding of the sites ie, ref style sheet.
According to the law, copy web design structure, encoding is a crime and Definitely could be legal issues in that.
If you are a newbie in web designing, I suggest you some of the top web designing blog that you should follow.
https://blog.hubspot.com/marketing/web-design-tips
https://blog.techreshape.com/5-web-design-tips-for-a-better-website-user-experience/
I am working on a mobile site for webkit browsers. I have been trying to find information on using multiple style sheets versus a single css file. There is a lot of information on this topic, but it not a lot of information pertaining to mobile browsers. My site will have a bunch of pages that while have page specific css.
For a non-mobile site, it seems like generally people say that a single file will be faster, but that multiple files are easier to develop. However, on a mobile site is that still the case?
If you put everything in one file, that will get cached after load, but that will make the first load slower. If you had page specific files, the first page would get loaded quicker, but every other page would then take a hit while making the page specific css http request.
Does anyone have any thoughts on this?
It sounds like they are saying one file is better as long as its under 1 MB (which my files def will)?
http://www.yuiblog.com/blog/2010/07/12/mobile-browser-cache-limits-revisited/
I would say that use multiple files for development, then when you deploy, minify them to a SINGLE file. I'm assuming that most mobile web browsers will do some kind of caching on your css files. Also I find it hard to imagine a minified mobile site's css file that would grow large enough to worry about really [unless you're doing things like inline/embedded css images]
I think the best approach is to take a look at the physical differences when your user agent is a mobile device such as the iPhone.
Typically an iPhone would be operating on a mobile network which would be considerably slower than the average internet connection your average computer would be connected to. This is the only real difference, there may be some subtle difference in the way the different networks operate meaning that separate requests could take longer on a mobile network, but that would be just speculation.
Any processing on the device itself would surely be trival, so in my opinion I recommend what I recommend for websites designed for regular user agents. Develop with multiple style sheets and then use a tool to minify everything into a single compressed file (separate when necessary, conditional IE etc.).
When I build for multiple platforms I use a default style sheet (global.css) for everything, then I write a media specific stylesheet (i.e. screen.css, print.css, handheld.css); from there I create exception stylesheets for specific instances (i.e. screen-ie.css, screen-ie7.css, handheld-iphone.css). This gives me the greatest flexibility for as many presentation methods as possible.
Once everything is exactly how I want it, I minify the "stack" for each instance. So in the case of iPhone: global.css + handheld.css + handheld-iphone.css = iphone.[YYYYMMDD].css to which I call via:
<!--[if !IE]>-->
<link media="only screen and (max-device-width: 480px)"
rel="stylesheet" type="text/css" href="/css/min/iphone.[YYYYMMDD].css"/>
<!--<![endif]-->
Load only what you need to minimize footprint.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
I'm trying to alter my site in such a way so that when people view it, they don't know it's powered by Drupal. So, was wondering if there are any signs that give this away that I should know about?
Some of the giveaways I know of, are:
When adding content, it will say "node/add".
If the following file exists: misc/favicon.ico
etc
I'm looking for similar stuff?
Let's look at a fairly customized page based on Drupal: http://gemini-lights.com/ (a random page from the Drupal sites repository).
There are many giveaways:
if you change www.example.com/link/link2 to www.example.com/?q=link/link2 and it still works and points to the right page
www.example.com/user/1 gives you a profile page
resources (imgs, css, etc) are in /sites/all|example.com/themes/ or sth similar
there are CSS classes applied to many key elements of the site (like body) that do not change appearance - Drupal uses them to provide some info about the state of the page (like <body class="front not-logged-in page-front-page two-sidebars">)
probably many others
My advice is: don't try too hard with hiding the CMS of your website, if a hacker wants to find out what CMS you are running, he/she will find out. I'd focus on keeping the CMS up-to-date (Drupal makes this easy) and also watching out which modules you are installing - they are the most likely attack vectors.
Since this question is still getting many hits, let me update it with an example of a website of a major company (one of the biggest telephone companies in Poland), that, to my (pleasant) surprise ,is using Drupal for its main site, http://dialog.pl/:
The usual giveaway pages like /user/1, /login, etc. redirect to main page, so you can see the creators of the site have done their homework ;)
...but the source of the page contains my favourite give away: the usage of the zen theme: urls like /sites/all/themes/zen-dialog-main-page/../zen/css/page-strona_glowna.php or CSS styles applied: <body class="front not-logged-in node-type-page two-sidebars">
One more give away is the update.php page that has the familiar Garland theme (props to Kevin for this one).
As you can see, it's still possible to tell that the website is using Drupal - and this is a website of a major corporation. So the above advice still holds: don't waste your resources on trying to hide the CMS you used, keep it up to date (that's why the update.php file is probably still in place), monitor security vulnerabilities, use strong passwords, etc.
You're wasting your time:
Obscurity is not a form of security. And trying to hide Drupal may only tempt a hacker to beat you.
If there is a security flaw, you will almost certainly miss it and the hacker only has to try a specific attack vector. He or she is not going to check if it's Drupal or not. Your attack may come from software that won't care.
The changes you make to hide Drupal may actually make your site less secure. Especially if you change the core and are no longer able to tell if your site is up-to-date.
It's very likely that the effort you spend hiding Drupal can, instead be applied to a proven, effective security policy and get better results.
Login page is /user or /user/login
Admin page is /admin or ?q=admin
/node displays a listing of the latest nodes
/node/n where n is a number displays the node with that number (for example /node/1 displays the first node ever created)
The word 'node' or 'views' in objects' classes in view source.
In things which are paginated, page 2 is actually displayed as page/1 or /1 in the URL (Drupal pagination URLs are sort of geeky like that).
Like others have said, don't worry too much about this. It's a waste of time. Just keep Drupal core and all your modules up to date (you can even set it to email you when security releases are released for your installed modules) and you shouldn't have to worry about a thing.
Quick ways to find out if a site is a Drupal site.
Browse the source code and search for or Drupal.settings (appears on all sites using the google analytics module)
go to www.example.com/CHANGELOG.txt if Drupalsite, will show the current version.
There are a lot of other ways that indicate if a site is a Drupal site, but the above is fast and certain.
Other signs would be.
markup:
<div id="node-2020 ... (divs with id node-[number])
<div class="views- ... (divs with a class of views-[something]
class="clear-block" (clear-block is the drupal implementation of the clear-fix CSS trick)
Urls:
node
node/[number]
node/add
admin -> giving 403
admin/build/modules -> giving a 403
HTTP Expires header set to Dries' (the creator of Drupal) birthday
greggles (lead of the Drupal Security team) wrote an article about hiding the fact a site is running Drupal: Hiding the fact your site runs Drupal OR fingerprinting a Drupal site.
Some of the things that allow to know when a site is using Drupal can be altered, but in some cases it is not worth, or it requires resources that would be better spent doing something else, such as making Drupal more secure, or avoiding security holes in the site.
For example, the messages given to the users from the modules are an indication the site is running Drupal (and what version exactly), but altering those messages would mean change them every time a new module is installed, or a new version of a module is installed. The CSS classes is something else that helps understanding when a site is running Drupal, but changing them is not that easy, as some modules depend on a specific CSS class to work. The fact the JavaScript code uses a Drupal object also helps in catching a Drupal site.
New Answer to old question. This site will tell you if a site is built with Drupal, and could give your game away. It does give false negatives though, so it might be worth it to test it out with that website and see how well you can obfuscate.
You can't really escape people's suspicions. To do so, you'd have to change file-systems, stylesheets, markup, etc. This is unreasonable. Why does it matter if you're using Drupal?
I find http://wappalyzer.com Chrome extension an excellent tool for detecting what a site is powered by. This goes beyond detecting just Drupal and lists many of the 3rd party tools and underlying technologies a site uses.
People who knows Drupal may identify it by the source. But Drupal has no Generator Header like Joomla or others.
The expires headers are pretty unique as well. In fact they are set to Dries Buytaert (creator of Drupal) date of birth. As far as I can tell they have been set like the below since Drupal 4.6.
Expires: Sun, 19 Nov 1978 05:00:00 GMT
Dead giveaway:
Try going to update.php, you'll get Access Denied (and the Garland theme).
Chrome has an add-on called Chrome Sniffer that shows what CMS any site is built on.