I want to give entirely custom url to my article
something like: /games/2010/junee2010/6/Dexter%20the%20Game.html
Because I am move html based site to Joomla and I want to save same urls for Google.
What extension or custom solution I need to use?
There are a couple of good SEF extensions that can probably do it -
http://extensions.joomla.org/extensions/site-management/sef/10134
http://extensions.joomla.org/extensions/site-management/sef/10019
However, I am not a big fan of using SEF extensions, the built in SEF works pretty well. Unless you have hundreds of articles you are moving, I would use 301 redirects and let Joomla build the URLs the way it would normally. One less thing to go wrong.
Related
My goal is to embed a full Ruby on Rails app in a Wordpress site. Ideally, the staff should be able to edit the non-Rails parts of the site just like any Wordpress site, including content, theme, menus, etc. When the user clicks a link to a certain page, it should show the Rails content within the Wordpress template—headers, menus, sidebars, etc.—all of which should look the same as the rest of the site. I'd much prefer to do the presentation of the Rails content within Rails, where I can use Slim, CoffeeScript, SASS, and all of the other built in presentational magic, rather than setting Rails up as just a JSON server and having to muck around with PHP to retrieve and format the data.
I've tried a few techniques so far, but each has its downsides:
First, I tried embedding the Rails app in an iframe, but iframes are clunky, and I couldn't get it to expand or contract to the height of the content.
Second, I tried creating a special Wordpress template file that loads the Rails content using PHP's file_get_contents function. That worked okay, but required a lot of jankiness to get URLs to transfer over, including having to add a question mark into the URL for a certain subpage to get Wordpress to ignore it and pass it through. It's also a little slow because it's loading content from two different dynamic systems. And I never could figure out how to get cookies to pass through to Rails, which is essential for this app.
My third solution was to create a blank page on Wordpress (not linked to anywhere) and write a method in Rails that pulls that page, creates a layout file, and then uses that as the layout for the content. So the whole page is actually being served by Rails, but to the user it looks just like Wordpress, and because Wordpress doesn't use relative URLs in links, they all work just fine. The trouble there is that changes to the Wordpress template (including menus, template files, theme options) don't take effect on the Rails pages until that method is run. I set up a cron job to run it every 15 minutes, but that's not ideal, and something tells me there must be a better way.
This seems like something that would be pretty common, but I haven't been able to find any solutions online. Has anyone else made this work?
Example:
You know the site about.com ?
They have a whole subset of url's such as: pottery.about.com
My question: How to get the "pottery" in front of the URL?
Anybody have some nifty mod_rewrite to do this?
Thanks!
David
Those are considered sub domains, you can set them up most of the time through any hosting company. Usually they dont charge you for them, but some do. They are very easy to setup and can be done quickly versus regular domain names.
I'm new to Django. Seems that Django requires to define one URL mapping rule for each controller/action (view/function in Django's term). What's the easiest way to implement Rails-style URL routing, or at least web2py-style URL routing?
For those who don't know what is Rails or web2py style URL routing.
Rails RESTful URL routing
web2py URL routing: http://domain.com/C/A maps to C controller A function automatically.
What you're trying to do goes explicitly against Django's design philosophy: "Tying URLs to Python function names is a Bad And Ugly Thing." So I think you have two easy choices and one hard one.
Easy #1: Stick with rails
Easy #2: Use django the way django is normally used: one URL rule per view.
Difficult: Write a generic URL dispatcher that uses introspection to look up view methods based on URLs. Be very careful making it secure. And share it when you're done. :)
Not saying you shouldn't do it. But if you're looking for an easy way to do this I suspect you'll be frustrated.
You can write it easily in custom way - write one view which accepts the url and parses it. then it loads module you want. Then you will have only one rule in urls.py file, which will call just one view function.
Also you can create middleware probably to solve the issue you have....
But I wouldn't recommend to do so and I think it is best to stick with the style of routing Django uses. Why? Because later then you will have to think about custom url resolvers, you will not be able to use for example {% url %} template tag (while you will not customize it also). I think it is not worth to reinvent something here... But this is only my opinion, it is you who decides :)
Have fun :)
I would recommend looking over the documentation for the Django URL dispatcher. There you should a bunch of ways to solve your problem. However if you are looking for a quick answer on a faster way to define your URL's then I would take a look at View Prefixes they cut down some of the bloat that you may be seeing.
If you are looking at REST then I would recommend taking a look at this article.
I am looking at implementing URLMapping for a personal project. I am already aware that solutions exist so please do not answer suggesting I should use one.
What I want is to harvest the opinions of fellow developers and web users on URL mapping implementations. Specially I would like you to answer:
Which is your favourite implementation?
What do you like about your favourite implementation?
What do you not like about your favourite implementation?
How would you improve it?
I would like you to answer from two points of view:
As a developer
As a user
I would be grateful for any opinions on this matter, thanks!
I've only worked with django's URLConf mechanism. I think the way it relies on the urlpatterns variable is a bit flimsy, but I like its expressiveness in specifying patterns and dispatching to other url configurations. I think probably the best thing is to figure out your URL scheme first, and then try out a couple of solutions to see what matches best. If you're going hard-core REST using the full complement of GET/POST/PUT/DELETE, and checking the user agent's Accept headers, and all that, django will, by default, have you splitting your logic between URL config files and view files, so it might not be the cleanest solution.
However, since it's all Python, you might be able to do some more complex processing before you assign to urlpatterns.
Really, you want a system that does what you need. Your URL scheme is your API, so don't compromise on it based on the tools you use. Figure out your API, then find the tools that will let you do that and get out of your way.
Edit: Also do a google search for "URL scheme design." I found this without much effort: http://www.gaffneyware.com/urldesign.htm. Not comprehensive, but some good advice gotten from looking at what flickr does.
Well, I should have noticed the url-routing tag shouldn't I? :-) Sorry about that.
jcd's experience mimics mine - Django is what I use too.
I like the fact that the routes for an app reside within the app (in urls.py) and can just be included into any projects that might make use of that app. I am comfortable with regular expressions, so having the routes be specified in regex doesn't phase me (but I've seen other programmers scratch their heads at some more uncommon expressions).
Being able to reverse a route via some identifier (in Django's case by route's name) is a must. Hardcoding urls in templates or controllers (view in Django) is a big no-no. Django has a template tag that uses the reverse() method
The one thing I wish I could do is have the concept of default routes in django (like Rails does or even Pylons). In Django every route has to map to a view method, there is no concept of trying to call a certain view based on the URL itself. The benefit is that there are no surprises - your urls.py is the Table of Contents for your project or app. The disadvantage is that urls.py tend to be longer.
Given my new understanding of the power of "includes" with PHP, it is my guess that ALL of my pages on my site will be .php extension.
Would this be considered strange?
I used to think that most pages would be .htm or .html, but in looking around the net, I am noticing that there really isn't any "standard".
I don't really think I have a choice, if I want to call my menus from a php file. It is just going to be that way, far as I can see... so just bouncing off you all to get a feel for what "real programmers" feel about such issues.
The thing that actually matters to the browser isn't the file's extension; it's the MIME Type that it gets sent in the HTTP headers. Headers are data that gets sent before the actual file and tell what kind of data it is, how big it is, and a bunch of other unimportant junk. You can configure your server to send any file extension as an HTML page, but the most common extensions for HTML pages are .htm, .html, .php, .asp, .aspx, .shtml, .jsp, and several others.
As for it looking "strange", a surprisingly small number of users will actually look at the address bar at all, let alone notice that the file extension is .php instead of .html. I wouldn't worry about it if I were you; it really doesn't make a difference.
generally - make sure your URLs are easily read, reflect the content beneath them, and don't change. the "not changing" part can be tricky, especially when you shift technologies over time (html>php>aspx).
to achieve this just ensure that each area of your site appears to reside in its own subdirectory.
mysite.com/news/
mysite.com/aboutus/
mysite.com/products/
etc.
you can either do this by physically structuring your site in this fashion and using default documents (default.html/php/aspx), or using something like mod rewrite, ISAPI rewrite, or similar to rewrite these paths to the appropriate docs.
someone who's keen on SEO or marketing might have a different idea about what constitutes a "good" URL, but as a developer this is how i see it.
Ending URLs in .php is fine technically, but I think these days many people are trying to make the urls independent of the actual code/file structure.
I actually think that's a good thing from a software engineering perspective as well. URLs are conceptually different (read: not related at all) to the file/directory structure used to organize the system powering the website.
The "resource" that a URL "locates" is not the .php or .asp file that contains the code to display it.
Look at stackoverflow for example, the URL of this question is /questions/322944/uql-etiquette, there's nothing in it that can be used to "guess" the underlying framework/system. The resource in this case is the question and all the answers to it, as well as the comments, votes, edits, and various other stuff.
It doesn't matter what your URLs end with, .php is fine, and fairly common. The only thing people care about these days when it comes to URLs is making them pretty for Search Engine Optimisation, but that's a whole new question.
Real programmers use URLs like /noun/verb/id/ & don't show file extensions at all :p
Personally I use Apache's mod-rewrite.
(on a slightly less tongue-in-cheek note) It's worth mentioning, specifically for includes, that you should ensure your actual files have the extension .php. I've seen more than one site where programming logic can be viewed in-browser 'cos the developer ended their files .inc (or insert non-auto-parsed extension of choice here).
As far as url etiquette goes - I really don't think etiquette is involved; however if you have sophisticated users visiting your website who have strong views on platforms and technologies, using .php or .aspx extensions could put off users - perhaps subconsciously.
If you use apache, it's fairly easy to make a .php be read as a .py and vice versa by changing the httpd.conf file. My current practice is to use .html extensions (or no extensions at all) and treat all files as .php.
Whatever you decide, do make sure that you never break an existing url. It's possible to achieve that even if you keep .php as the extension and decide to change the technology later.