I want to be able to write javascript that executes on a page that I visit every day. It is for my employers blog-like "What's New" page where there are announcements such as new hires, terminations, etc. But among these are also article that announcing grants we received and other important things.
I want to filter out those things that I don't care about but keep those that I do. I could do this with CSS if there were selectors that I could match on. But there are none that seperate those posts from the ones I don't care about.
So, is there a way in Firefox to specify a js file that would act on a certain URL? Like there is a user defined userChrome.css that matches on all CSS in a page?
Thanks
Eric
You want Greasemonkey. Despite the name that makes you go ewwwww, it is a very powerful and useful tool.
Related
Why is it a bad idea to have a ID in the URL in terms of SEO? How does this URL
http://example.com/user/1234 hurt SEO?
Can someone give me a practical example where search engine rankings are worse?
The reason people are saying that {ID} in the URL is bad is due to the way search engine algorithms work. When a search term is located in the actual URL, it is weighted much more heavily than the content of the page, etc.
For example:
<!-- http://example.com/blog/57 -->
<html><head><title>An article on search engine optimization</title>...
vs
<!-- http://example.com/blog/an-article-on-search-engine-optimization -->
<html><head><title>An article on search engine optimization</title>...
If you do a search in Google for "Search Engine Optimization" the second page, the one with the slug in the url will weight as a better result than the one with only the id.
You can deal with this in the same way that stack overflow deals with this issue:
http://stackoverflow.com/questions/{id}/{slug}
http://stackoverflow.com/questions/910683/why-is-id-in-the-url-a-bad-idea
The combined id and slug format really helps you achieve the best of both worlds. You get the ease of programming by retrieving records by {id}, but you also retain the optimized search URL because of the {slug}.
It does have an effect of the click-through rate.
The url is presented in green below the search result - so if it contains relevant words the user might click your site and not another site.
Which would you rather click:
www.test.com/page.php?u=85583
OR
www.test.com/Solution-to-your-problem.php
As commented this effect may be achieved even with urls including an id.
In the olden days it search engines treated words in url with much respect and gave those pages extra credit and higher ranking. This effect has almost vanished. We are left with two other effects of readable urls:
Clickthrough
Linkbuilding: Easier for a human to copy such a url and after the link is copied it is often referred to with some of the slug words. The url with "Solution-to-your-problem" may have Solution to your problem inside the a tag also when people link to your page. This will influence your ranking.
A solution with id + slug might be the best solution and it fixes the problem of keeping track of slug changes.
test.com/85583/solution-to-your-problem
But there are some rules to follow, you should do a 301 redirect if the slug is incorrect to prevent a lot of duplicate content pages. Spam/duplicate content detecting kicks in if you got a lot of similiar pages:
test.com/85583/solution-to-your-problem
test.com/85583/solution-to-yar-problem
test.com/85583/evil-competitor-spamming-you-haha
Including the id also requires your ids to be as short as possible, an url with a full guid might be confusing to the eye and prevent a good clickthrough:
test.com/0CD03822-4A35-11DE-BF38-3F9356D89593/solution-to-yar-problem
Remember that Google News even demanded that you had an id in your url to be included.
Well, my name is Sudhir Jonathan, so if I want people to find me on your site, example.com/user/sudhir-jonathan is much much better than example.com/user/1234. Simply because the object of your page - "Sudhir Jonathan" - is now present in the url itself. This is a big win.
Similarly, example.com/articles/how-to-bake-a-cake is ranked much higher than example.com/articles/2379797 for the search term "bake a cake".
See this Do SEO-friendly URLs really affect a page’s ranking? question. Based on the answers, no-one can find any proof that IDs in the URLs has any effect on SEO.
It simple, search engines care words rather than number. That is to say, it will be better to see keywords in url than just ID sine ID/number is useless for search engines to determine whether your site is relevant or not!
It's always a bad idea to provide unusual information. Try the user name instead!
For SEO there is no real advantage/disadvantage between static ID urls and username urls.
1) you miss out on keywords in the url
2) it's harder for a human to read and understand what the link will be about
3) sql injection is a lot easier with IDs
I am an amateur programmer and I want to make a mulitlingual website. My questions are: (For my purposes let the English website be website nr 1 and the Polish nr 2)
Should it be en.example.com and pl.example.com or maybe example.com/en and example.com/pl?
Should I make the full website in one language and then translate it?
How to translate it? Using XML or what? Should website 1 and website 2 be different html files or is there a way to translate a html file and then show the translation using XML or something?
If You need any code or something tell me. Thank You in advance :)
1) I don't think it makes much difference. The most important thing is to ensure that Google can crawl both languages, so don't rely on JavaScript to switch between languages, have everything done server side so both languages can be crawled and ranked in Google.
2) You can do one translation then the other, you just have to ensure that the layout expands to accommodate more/less text without breaking it. Maybe use lorem ipsum whilst designing.
3) I would put the translations into a database and then call that particular translation depending on whether it is EN or PL in the domain name. Ensure that the webpage and database are UTF-8 encoding otherwise you will find that you get 'funny' characters being displayed.
My Advice is that you start to use any Framework.
For instance if you use CakePHP then you have to write
__('My name is')
and in translate file
msgid "My name is"
msgstr "Nazywam się"
Then you can easy translate to any other language and its pretty easy to implement.
Also if you do not want to use Framework you can check this link to see example how it works:
http://tympanus.net/codrops/2009/12/30/easy-php-site-translation/
While this question probably is not a good SO question due to its broad nature. It might be relevant to many users.
My approach would be templates.
Your suggestion of having two html files is bad for the obvious reason of duplication- say you need to change something in your site. You would always need to change two html files- bad.
Having one html file and then parsing it and translating it sounds like a massive headache.
Some templating framework could help you massively. I have been using Smarty, but that's a personal choice and there are many options here.
The idea is you make a template file for your html and instead of actual content you use labels. Then in your php code you include the correct language depending on cookies, user settings or session data.
Storing labels is another issue here. Storing them in a database is a good option, however, remember you do not wish to make 100's of queries against a database for fetching each label. What you can do is store them in a database and then have it generate a language file- an array of labels->translations for faster access and regenerate these files whenever you add/update labels.
Or you can skip the database altogether and just store them in files, however, as these grow they might not be as easy to maintain.
I think the easiest mistake for an "amateur programmer" to make in this area is to allow the two (or more) language versions of the site to diverge. (I've seen so-called professionals make that mistake too...) You need to design it so everything that's common between the two versions is shared, so that when the time comes to make changes, you only need to make the changes in one place. The way you do this will depend on your choice of tools, and I'm not going to start advising on that, because it depends on many factors, for example the extent to which your content is database-oriented.
Closely related to this are questions of who is doing the translation, how the technical developers and the translators work together, and how to keep track of which content needs to be re-translated when it changes. These are essentially process questions rather than coding questions, so not a good fit for SO.
Don't expect that a site for one language can be translated without any technical impact; you will find you have made all sorts of assumptions about the length of strings, the order of fields, about character coding and fonts, and about cultural things like postcodes, that turn out to be invalid when you try to convert the site to a different language.
You could make 2 different language files and use php constants to define the text you want to translate for example:
lang_pl.php:
define("_TEST", "polish translation");
lang_en.php:
define("_TEST", "English translation");
now you could make a choice for the user between polish or english translation and based on that you can include the language file.
So if you would have a text field you put its value to _TEST (inbetween php brackets).
and it would show the translation of the chosen option.
The place i worked was doing it like this: they didn't have to much writing on their site, so they were keeping it in a database. As your tags have a php , I assume you know how to use databases. They had a mysql table called languages with language id(in your case 1 for en and 2 for pl) and texts in columns. So the column names were main heading, intro_text, about_us... when the user comes it selects the language and a php request get the page with that language. This is easy because your content is static and can be translated before site gets online, if your content is dynamic(users add content) you may need to use a translation machine because you cannot expect your users to write their entry in all languages.
I'm trying to make an automated process to retrieve some information from a site on my work network.
var duderegex = new RegExp("Title for Mr. [^\n]+","m");
var dude = duderegex.exec(input);
So far, so good. The problem is that I'm writing this on my work computer and probably won't be able to convince anyone to store this on the same domain as the site that is hosting it. So that technically makes it XSS. And I'd rather not have to get approval to install anything seriously funky (so I can't guarantee JQuery or a powershell that's easier to copy/paste from, for example).
I don't have any problems downloading files and manipulating them via webpage after download, but that adds a step clicking Save As...
Does anyone have any workable solutions for running regex on HTML source from a different domain? I don't need to limit it to Javascript, but getting PHP to work, for example, might require more resources than I have.
A commenter asked for clarification, so here goes. Let's say I have to contact 50 copyright holders a day (it has nothing to do with intellectual property but it will work). Right now, I have a form that takes me to
(1) http://foo.bar/form.htm?action=search&type=ArtistAlbum&Artist=Beatles&Album=White
and redirects to
(2) http://foo.bar/form.htm?id=4578469
From there, I click on a dropdown (let's say track listing), and that takes me to
(3) http://foo.bar/form.htm?id=4578469&track=7
There I have an alphabetical list of everyone who worked on the track, their agents, and legal representatives. I'm only interested in three names, the name of the person who holds the copyright of the lyrics, the name of the person who holds the copyright for the melody, and the name of the person who holds the copyright of the recording. So I have to search the document three times.
Since each name has a standard title, I should be able to write a script that asks for the artist and album, generates the link to (1), either copies the param from the url for (2) or uses a regex to find it from the link to (3), loads page (3), and then generates the output for a regex on the strings
/Lyrics Copyright Holder [^\n]+/
/Melody Copyright Holder [^\n]+/
/Performance Copyright Holder [^\n]+/
I could download all the files (it would take a long time), but the information changes on occasion, and I want to make sure I'm always pulling the newest information.
But I can't seem to get around the XSS bit.
You don't say what problem you're really trying to solve so it's a little hard to know what solutions make the most sense for you, but you can write javascript that works on any web page in a browser plug-in (like in Chrome or Firefox) or by using a scripting language outside of a browser (Python, Javascript, PHP, etc...) where you load the page contents and then manipulate the contents using the language tools.
I'm integrating an external application to SharePoint 2010 by developing custom ribbon tabs, groups, controls and commands that are made available to editors of a SharePoint 2010 site. The ribbon commands use the dialog framework to open dialogs with custom application pages.
In order to pass a number of query string parameters to the custom applications pages, I'm therefore looking for the equivalent of SPContext.Current.ListItem in the Client Object Model (ECMAScript).
Regarding available tokens (i.e. {ListItemId} or {SelectedItemId}) that can be used in the declarative XML, I already emitting all tokens, but unfortunately the desired tokens are not either not parsed or simply null, while in the context of a Publishing Page (i.e. http://domain/pages/page.aspx). Thus, none of the tokes that do render, are of use to establishing the context of the calling SPListItem in the application page.
Looking at the SP.ClientContext.get_current() provides a lot of information about the current SPSite, SPWeb etc. but nothing about the current SPListItem I'm currently positioned at (again, having the page rendered in the context of a Publishing Page).
What I've come up with so far is the idea of passing in the url of the current page (i.e. document.location.href) and parse that in the application page - however, it feels like I'm going in the wrong direction, and SharePoint surely should be able to provide this information.
I'm not sure this is a great answer, or even fully on-topic, but is basically something I originally intended to blog about - anyway:
It is indeed a pain that the Client OM does not seem to provide a method/property with details of the current SPListItem. However, I'd venture to say that this is a simple concept, but actually has quite wide-ranging implications in SharePoint which aren't apparent until you stop to think about it.
Consider:
Although a redirect exists, a discussion post can be surfaced on 2 or 3 different URLs (e.g. Threaded.aspx/Flat.aspx)
Similarly, a blog post can exist on a couple (Post.aspx/EditPost.aspx, maybe one other)
A list item obviously has DispForm.aspx/EditForm.aspx and (sort of) NewForm.aspx
Also for even for items with an associated SPFile (e.g. document, publishing page), consider that these URLs represent the same item:
http://mydomain/sites/someSite/someLib/Forms/DispForm.aspx?ID=x, http://mydomain/sites/someSite/someLib/Filename.aspx
Also, there could be other content types outside of this set which have a similar deal
In our case, we wanted to 'hang' data off internal and external items (e.g. likes, comments). We thought "well everything in SharePoint has a URL, so that could be a sensible way to identify an item". Big mistake, and I'm still kicking myself for falling into it. It's almost like we need some kind of 'normalizeUrl' method in the API if we wanted to use URLs in this way.
Did you ever notice the PageUrlNormalization class in Microsoft.SharePoint.Utilities? Sounds promising doesn't it? Unfortunately that appears to do something which isn't what I describe above - it doesn't work across the variations of content types etc (but does deal with extended web apps, HTTP/HTTPS etc).
To cut a long story short, we decided the best approach was to make the server emit details which allowed us to identify the current SPListItem when passed back to the server (e.g. in an AJAX request). We hide the 'canonical' list item ID in a JavaScript variable or hidden input field (whatever really), and these are evaluated when back at the server to re-obtain the list item. Not as efficient as obtaining everything from context, but for us it's OK because we only need to resolve when the user clicks something, not on every page load. By canonical, I mean:
SiteID|WebID|ListID|ListItemID
IIRC, one of the key objects has a CanonicalId property (or maybe it's internal), which may help you build such a string.
So in terms of using the window.location.href, I'd avoid that if you're in vaguely the same situation as us. Suggest considering an approach similar to the one we used, but do remember that there are some locations (e.g. certain forms) where even on the server SPContext.Current.ListItem is null, despite the fact that SPContext.Current.Web (and possibly SPContext.Current.List) are populated.
In summary - IDs are your friend, URLs are not.
Currently our website uses links to allow the user to change their locale. The problem with this is that you get a lot of random outlinks from each page on the site to... the same page, in other languages. When a search engine traverses this, it gets an excessively complex view of the site.
We were going to change it to a form post to avoid this. However, it seems to me that we should just be able to change it to an onclick="window.location.href='change_my_language.php'" rather than an href="change_my_language.php". Am I right? Or do the major search engines scan for and follow this sort of thing nowadays?
To solve the larger problem of duplicate content, you can use the canonical link tag to specify on the pages in other languages the URL of the preferred document.
<!-- on http://www.example.com/article.php?id=123&language=something-else -->
<link rel="canonical" href="http://www.example.com/article.php?id=123" />
To save search engines the trouble of landing on the other pages, it wouldn't hurt to add rel="nofollow" to the links, to ensure that robots don't waste their time checking them out. However, the canonical link tag is still vital, in case someone links to your other-language content, to ensure that your preferred page gets the ranking credit.
I'm fairly certain search engines don't parse JavaScript, so any code that changes the value of any property of the location object wouldn't follow the URL.
EDIT
An interesting article on the topic: http://www.seroundtable.com/archives/019026.html
and bobince's answer on this potential duplicate question suggests the same: window.location and SEO
POST method must be used when the request changes server's state, i.e. request has side-effects:
http://www.cs.tut.fi/~jkorpela/forms/methods.html
No, search engines won't be able to follow javascript links, but POST is more elegant solution.
When a search engine traverses this, it gets an excessively complex view of the site.
This should not be a problem. As long as you are correctly marking up each page with lang="...", the search engine should know what to do with it. What is the actual problem you are facing that leads you to believe search engines are confused by a ‘complex’ link map?
You can give them a sitemap if you really want to be explicit.
However, it seems to me that we should just be able to change it to an onclick="window.location.href='change_my_language.php'" rather than an href="change_my_language.php"
That would degrade the site's usability and accessibility a little as well as (deliberately) sabotaging the search engine.
In any case, whatever you do you should definitely leave each language version on its own URL (eg. /en/category/title) rather than totally relying on a language-setting cookie, or you really do run the risk of confusing search engines. Normally you do want search engines to index every language version you have, to catch searches from users of other languages.
Google is getting increasingly better at parsing JavaScript. I don't think that the search engines will follow this link now...but to be more certain they don't follow you can change your anchor tags to spans instead and use the onclick="document.location='url'" method.
Though what you may want to do is add rel="nofollow" to these links instead. You can also add a canonical link to the main page.