Wordpress tends to strip out all kinds of code in VISUAL mode, including microformatting. The current WP (3.2.1) seems beyond compatibility with earlier widgets, including wp-RDFa (which I thought showed promise). As discussed in [this Google group post]https://groups.google.com/forum/#!topic/schemaorg-discussion/E72kDkuguk4/discussion, clients often need to use VISUAL, thus the problem in using any kind of microformatting with Wordpress. Yet we want to start using microformats of some kind. (Damn you wordpress!)
Suggestions please?
Still early days for this plugin, but give it a try...
http://schemaforwordpress.com/
Is it OK if everything looking OK but HTML and CSS are not valid , for CMS Admin/control panel?
Should we only consider Web-standards for site, not necessary for site-management tools?
for example
:http://example.com/wp-admin
:http://example.com/admin/
Well, the point of standards compliance is to make everything work correctly for every user. Even though admin areas are only accessible to a few select users per site, if you are building a CMS you have to consider that many, many people might use your script which would add additional users who will be needing to access those admin panels. It's best to make everything standards compliant, that's why they create them. If an admin can't get the admin panel working properly, they'll ditch the script.
I agree it may not be worthwhile to to make everything valid. As long as you've done your testing and it working then it's probably not worth the time to make everything valid.
Some validation errors matter, some don't. The spec is a bit ridiculous in its requirements in places. What is important is that all open tags are closed and they are nested correctly as if this is not done there can be many subtle errors both now and in the future. As for non-encoded entities, using rel's and targets when you shouldn't - it doesn't matter so much.
Since you (usually) can control the access to the admin area (rather than normally having every single device and platform access it) it certainly matters less. The time would probably be better spent adding more features and fixing real bugs rather than aiming for 100% compliance. Don't tell any standards advocates I said that though. :)
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.
I'm searching for a way to put widgets from several services (PicasaWeb, Yahoo Pipes, Delicious bookmarks, etc.) on the community site I host on Plone (currently 3.2.1). I'm looking for a way to allow a group of users to use dangerous html tags.
There are some ways I see, but I don't know how to implement those. One would be changing safe_html for the pages editors own (1). Another would be to allow those tags on some subtree (2). And yet another finding an equivalent of "static text portlet" that would display in the middle panel (3). We could then use some of the composite products (I stumbled upon Collage and CMFContentPanels), to include the unsafe content on other sites.
My site has been ridden by advert bots, so I don't want to remove the filtering all together. I don't have an easy (no false positives) way of checking which users are bots, so deploying captcha now wouldn't help either.
The question is: How to implement any of those solutions?
(I already asked that on plone mailing list without an answer, so I thought I would give it another try here.)
Solution (3):
Use TAL portlet to add non-filtered HTML/JS snippets
Use ContentWellPortlets to show these portlets above or below your content.
I haven't used Plone 3.2 but there were some tools in the root directory of the Plone site when using the ZMI that allowed this. I can't remember if it was in "portal_transforms" or not, but I think so. It allows you to specify what tags in the HTML are allowed. I don't remember if it was something that you could control using the security settings (e.g. role based) or whether it was just a site wide setting.
Sorry for the vagueness but I just figured since you haven't gotten an answer that I'd tell you what I knew (little as that may be).
In Plone Site Setup there is a configlet for HTML Filtering. That may be useful.
PS: SO makes it so hard to help if your points is less than 125. May be I will just stick to the plone users mailing list.
PPS: That should make the answer "more complete"
Has anyone ever tried to integrate AspDotNetStorefront and Sitecore? I've been trying for the past couple of days to come up with a way to get the two systems to play nicely together, but it doesn't seem feasible from what I can tell. A couple issues I've run across so far:
Authentication between the two (AspDotNetStorefront has its own implementation, Sitecore just uses/extends .NET Membership)
The main DLL for AspDotNetStorefront is what pops up in the stack trace when I get yellow-screened, but that DLL is obfuscated so I can't figure out what the problem is.
The biggest issue is that we need to keep our existing AspDotNetStorefront application as an e-commerce backend and use Sitecore to do everything else. AspDotNetStorefront has a CMS as part of it, but it's really not an acceptable solution for anything but really basic content pages.
Any thoughts on how I might go about this?
EDIT:
I've decided to break this whole thing down into the different problems that I am facing at the moment and solve each one as efficiently as I know how. I'll detail the ones I have here and then update when I run into new ones.
Problem 1: Authentication between the two systems.
This one isn't too bad actually if you're knowledgeable about forms authentication tickets, which I wasn't at the time but am learning quickly enough. As long as the two systems share the same encryption info, it's easy enough to pass information back and forth between them using cookies as stated below in the accepted answer. The other kicker is that I needed to set the CustomerGUID in the AspDotNetStorefront Customer table to be the user ID from the Sitecore user tables (standard ASP.NET membership). So far this approach seems to work pretty well (I'm still in the proof of concept stage at the moment.
Another thing to keep in mind if you ever need to attempt this is that AspDotNetStorefront comes with a web service that you can use to basically do anything you need. Since they use the same encryption keys, I am able to log in on the storefront side using this service more securely than just passing over clear text passwords (I had to write the method myself, I don't believe it comes standard, if I am mistaken please let me know). Although I doubt it's a huge deal since it all happens server side anyways.
Problem 2: Getting at the product data
This one was a little more troublesome. The aforementioned web service has a few issues I've had difficulty working around. However, since the databases are going to be on the same server, I simply decided that since all I really need is the price and ID I would go ahead and set the ProductGUID column of each product in the Storefront database to match the Sitecore item ID of the corresponding item in the Sitecore database. This way I just need a quick query to grab the ProductID and price information which is only used in a few places. Everything else is going to be housed in Sitecore.
If anyone has anything to add feel free, as far as I can tell from Google, no one has actually done this before, so I'm having a lot of trouble finding resources on this particular topic.
UPDATE:
The integration is in fact possible and our site has been up for a week and a half now with very few integration related problems. This isn't something I recommend doing really on a personal level, but it is in fact possible to pull off.
I know ASPDotNetStorefront and other CMS systems (but not Sitecore). If I was approaching this, I would probably start simple and create a custom URL structure for sitecore 'content' pages that ASPDNSF would direct to Sitecore to handle. [possibly replacing the existing topics system in ASPDNSF]. So, for example: a URL such as www.domain.com/p-1234-aproductpage.aspx would be handled by ASPDNSF whereas www.domain.com/content/123/a-content-page would get sent to Sitecore to render. This is a straightforward web.config edit.
Security sharing across the systems should be possible across the same domain as the cookie information will be available (you should be able to create some code in Sitecore using the ASPDNSFCommon.dll and a cast of HttpContext.Current.User into a AspDotNetStorefrontPrincipal class to detect if a customer is logged in)
Another way to approach the problem would be to write a function that retrieved Sitecore content from the database based on a URL id and then write an ASPDNSF XML template to use the function to retrieve this content based on the URL. For example, you could create a custom URL structure in ASPDNSF such as www.domain.com/sc-1234-sitecore-content-item.aspx which is sent to your custom code; 1234 is used as the sitecore content id and the XML template retrieves the content and renders it on screen.
This second approach has the advantage of using Sitecore for all non-product content management while keeping the live application in ASPDNSF. Also one set of design templates and all your security issues go.