I wanted to register a domain name for myself but as usual could not get exactly the name I wished for.
Ex: 11minutes.com was what I wanted.
But I found a very similar one with a hyphen in between.
Ex:11-minutes.com
Are there any disadvantages to buying this domain ?
One down side is that people looking for the 11-minutes version might type the other variant into their browser address bar and go to the wrong site.
Another is that if the version already registered is a trademark in the same business as you, they could decide you're infringing and have your domain taken away.
It's better to have something distinct in most cases.
Related
I am using the latest versions on 2sxc (11.05) and the Content App on DNN 9.06. The Content-Type for Locations does not have a field for Region (or State). Is there already something in place to account for that to get Canadian or US addresses to output normally? I realize I can add the field and then maybe use the Dropdown from Query to hook it up to DNN's list of Regions, and then modify the Views accordingly...
But that seems like a lot of work for something that might already be built in (and I just don't see it?). Or is there another easy way to tackle this?
Truth be told - we never needed that so far, so it doesn't exist.
Is this necessary for maps to work, or just another field which a standard us-address needs? I'm curious because neither outlook nor SharePoint seem to require such a field, so I never really thought about it.
BUT: if you do implement it, please do share it back with us, so we can publish it.
Note that if this is important, a possibly nicer solution would be to use a public api somewhere which provides this information, as it's most certainly more complete & up to date for this purpose. If this is the case, ping me and I'll implement a string-dropdown-from-json or something like that :)
There are so many top level domains these days, like .xxx, .club and so on.
How do I check if some domain's top-level domain is correct and exists?
For example, mydomain.xyz. I can cut off mydomain. and check the rule against xyz. Should I get a full list somewhere? I suppose it's not 100% guaranteed as the list can grow over time?
Or may be I should use some remote API for this?
I found this one http://data.iana.org/TLD/tlds-alpha-by-domain.txt and it seems to be the one that I hope is updated regularly. Is it a good enough source?
Please advise.
If you want to check a given string to see if there is a currently existing TLD with that name, you can send an NS query for the name to the root servers and see if they give you a sensible answer. If they do, the TLD exists. If they do not, it does not exist.
If you want a list of all currently existing TLDs, the URL you give in your question is indeed the correct place to get one. As the first line in the file indicates, it does get updated regularly.
I have this requirement:
We have a journalarticle and we wish to have sections which have content for internal and external users for the application.
We are able to hide the content from rendering by implementing custom template on web content display and using a simple custom-field for a user which helps us to classify it.
Having said that when we search something as an external user, the search portlet is able to fetch an article where the search text is a part of internal user content, and due to the above mentioned template the content is not visible.
In short, from the user's perspective the resultant article does not match the searched term.
I wish to seek some pointer to check whether there is a mechanism to ensure that when an external user searches something then we only search the dynamic-element of the doc which matches the user type?
We have thousands of such articles and create multiple copy of the same article does not seems viable solution.. so any pointers would be a great help.
Liferay version : 6.2 GA4 CE
Thanks!
AJ
First of all: Not finding a search term in a document can be a sign of good working synonym resolution in the search engine. It's questionable if this behaviour is always wrong or only in this particular case. Remember google bombs?
That being said, I believe that this architecture of half-visible documents is flawed from the beginning. Ideally I'd suggest to change it, for example by splitting the information to two articles, so that you can use the standard permissions to resolve. If you link both, you can determine how/which article or template to use. It's not an ideal solution, but might be a workaround.
Another workaround might be to change Liferay's indexer component and index two different versions of the article, with two different permissions. Of course, you'll have to change the search side as well, so that you'll find each article at most once, even if it's now twice in the search engine.
Again - not ideal, but might be the quickest fix that you can get right now without changing the underlying architecture. However, to change the underlying architecture is my actual recommendation.
Hey guys! Working on a new Cake app and wondering if there is anyway for me to remove the ID-in-URL routing from Cake. Perhaps by passing the ID in POST somehow? Having the ID passed in as a URL param just seems really shoddy and unsafe. Thanks!
"Shoddy"? It's standard practice and a perfectly fine solution to have ids in the URL. Look at the URL of your question:
http://stackoverflow.com/questions/4638262/removing-id-from-cakephp-url
^^^^^^^
id
Also, there's absolutely nothing unsafe about showing an id in a URL. It's just a number that doesn't mean anything. If a user can do something "bad" only by knowing this id, your app is broken and insecure, not the id-passing mechanism.
Trying to work around this scheme means working around the fundamental principle of the HTML protocol and opens up a whole new can of worms.
Some people prefer using slugs instead of primary key ids. This is the removing-id-from-cakephp-url part of the URL from this page. Take a look at the SluggableBehavior.
However, slugs can change. Hence, having the primary key in your URL is useful if you want to have a permalink. StackOverflow does both so that it can support both permalinking from other sites, as well as for SEO reasons. :)
Regarding security issues, I guess the other answers have already pointed out that there are other ways to make your application secure.
Why do you care? URL-s are optimized for SEO reasons, an ID won't matter if it's ain't too long. If the latter, consider using a shorter one with numbers and letters in them instead, it will be as difficult to guess as a long one with just numbers.
If you are not using GET and you do not supply the params in the URL, your users won't be able to copy-paste the location.
I've searched a lot for the answer to this question - but can't find one - possibly it is just too stupid, in which case please forgive me!
I want to add og metadata to our pages, but the information for each logical object (in our case a sports team or player) can be spread across multiple actual URLs (eg /team/, /team/players/, /team/results/ are all logically part of /team/).
Can I put the same opengraph metadata on multiple pages that represent the same object?
Or alternatively, can I specify the og:url as a regex, eg: /team/* ?
Or does /team/ imply /team/* for an og:url ?
Thanks very much for any clarification, Mike
the information for each logical object (in our case a sports team or player) can be spread across multiple actual URLs (eg /team/, /team/players/, /team/results/ are all logically part of /team/).
Do you mean all of these URLs contain the same information (they are just different points of access to that info) – or do you mean the info is spread in „bits and pieces” over these URLs (and a user would have to visit them all to get all the info)?
I’m not sure I understand your question/problem here – but maybe you’re just looking for what’s called a canonical URL …?
You could call in every subpage the Open Graph API passing the parent page as object; no need to put metadata also on subpages, if you are not interested in having subpages as separate objects. This way, a like clicked on an individual page is always given to the team. You might use a custom property to specify from where the click arrived (or even the ref property, maybe).
On a side note, I would not tell that results are logically part_of the team. Although for this specific usage, it does not matter.