And, of course, there is also the Wordpress option.
The admin can choose from among different structures, or even create his/her own...
http://codex.wordpress.org/Using_Permalinks
SEO URLs
Forum rules
Please do not post support questions regarding installing, updating, or upgrading phpBB 3.3.x. If you need support for phpBB 3.3.x please visit the 3.3.x Support Forum on phpbb.com.
If you have questions regarding writing extensions please post in Extension Writers Discussion to receive proper guidance from our staff and community.
Please do not post support questions regarding installing, updating, or upgrading phpBB 3.3.x. If you need support for phpBB 3.3.x please visit the 3.3.x Support Forum on phpbb.com.
If you have questions regarding writing extensions please post in Extension Writers Discussion to receive proper guidance from our staff and community.
- sooskriszta
- Registered User
- Posts: 85
- Joined: Wed Dec 29, 2010 7:23 pm
Re: SEO URLs
OC2PS
Testfestés, Arcfestés, Csillámfestés
Alapanyagok, Képzések, Ismertetők
Hennafestés
GMAT coaching and MBA Admissions Consulting
formerly known as sooskriszta
Testfestés, Arcfestés, Csillámfestés
Alapanyagok, Képzések, Ismertetők
Hennafestés
GMAT coaching and MBA Admissions Consulting
formerly known as sooskriszta
Re: SEO URLs
TBH I don't like the excess of ///// makes the url looks ugly to me...
But I think just adding the topic title and dropping the f= parameters is enough.. Keeps the url nice and clean.. ppl know what the url is linking too..
But I think just adding the topic title and dropping the f= parameters is enough.. Keeps the url nice and clean.. ppl know what the url is linking too..
ø = 1.618033988749895...
Everything has ø in it
Everything has ø in it
- sooskriszta
- Registered User
- Posts: 85
- Joined: Wed Dec 29, 2010 7:23 pm
Re: SEO URLs
I do prefer / to ? et al
It could be familiarity - slashes are the logical hierarchical separators in most, if not all, operating systems, as well as in web URLs...
It could be familiarity - slashes are the logical hierarchical separators in most, if not all, operating systems, as well as in web URLs...
OC2PS
Testfestés, Arcfestés, Csillámfestés
Alapanyagok, Képzések, Ismertetők
Hennafestés
GMAT coaching and MBA Admissions Consulting
formerly known as sooskriszta
Testfestés, Arcfestés, Csillámfestés
Alapanyagok, Képzések, Ismertetők
Hennafestés
GMAT coaching and MBA Admissions Consulting
formerly known as sooskriszta
-
- Registered User
- Posts: 5
- Joined: Fri Feb 11, 2011 4:32 am
Re: SEO URLs
Seems to me that perhaps we need to editions of PhPBB: one for the internal company or organization users, and one for people who create websites for public online communities. The more I read these forums, the more I realize that there is a serious collision point in between these two groups, and these two groups need slightly different features. The solution is to make these features turn on or off at will. if you have to have a secret forum, then by all means, don't encode anything in the URL.
However, SEO optimized URLs aren't just for the benefit of search engines. They are part of modern usability. No one should have to work with complicated computer URLs. The idea behind SEO URLS is that they are human friendly. It's easier for me to remember /cars/ then it is to remember /viewforum.php?f=2.
If your forum is secret, and you get to read the forum, then your URL should still be human friendly to you. If it has to be so secret that you can't have the topic show up in the URL, then turn the SEO feature off. But SEO needs to be part of the next release.
However, SEO optimized URLs aren't just for the benefit of search engines. They are part of modern usability. No one should have to work with complicated computer URLs. The idea behind SEO URLS is that they are human friendly. It's easier for me to remember /cars/ then it is to remember /viewforum.php?f=2.
If your forum is secret, and you get to read the forum, then your URL should still be human friendly to you. If it has to be so secret that you can't have the topic show up in the URL, then turn the SEO feature off. But SEO needs to be part of the next release.
Re: SEO URLs
Before using PHPBB, I used IPB (up to version 2.0)
In all IPB pages, the same function gets called just before sending content to the browser.
I had seen a mod using that to change the URLs with str_replace() and preg_replace() functions. All URLs that could be seen by a search engine bot (public URLs) where changed to a prettier URL.
A .htaccess file was used to process the URL-rewriting and redirect the queries to the correct URLs.
The huge advantage with that method is that there's only one file to modify to change the URLs :
- create a new function pretty_urls() that makes the necessary str_replace() and/or preg_replace() calls to modify the URLs in the page to be sent
- add a call to pretty_urls() inside the function call_me_before_display()
Note: don't look for pretty_urls() or call_me_before_display() functions, I invented these names.
There's a PHPBB mod called PHPBB SEO. The result is good, but it requires lots of changes in many files to be installed. When you decide to install other mods or upgrade your PHPBB installation, all the changes are to be done again
With the changes I described, a mod like PHPBB SEO would be really much easier to install.
About the usefulness of SEO :
If you don't want to use SEO, don't use it. If you want to use it, do so.
I think having prettier URLs is a part of SEO, but there's much more: having good content, being known (backlinks...)
I'm not asking PHPBB to solve the problems caused by URL rewriting (like duplicate content), this is not PHPBB's role.
In all IPB pages, the same function gets called just before sending content to the browser.
I had seen a mod using that to change the URLs with str_replace() and preg_replace() functions. All URLs that could be seen by a search engine bot (public URLs) where changed to a prettier URL.
A .htaccess file was used to process the URL-rewriting and redirect the queries to the correct URLs.
The huge advantage with that method is that there's only one file to modify to change the URLs :
- create a new function pretty_urls() that makes the necessary str_replace() and/or preg_replace() calls to modify the URLs in the page to be sent
- add a call to pretty_urls() inside the function call_me_before_display()
Note: don't look for pretty_urls() or call_me_before_display() functions, I invented these names.
There's a PHPBB mod called PHPBB SEO. The result is good, but it requires lots of changes in many files to be installed. When you decide to install other mods or upgrade your PHPBB installation, all the changes are to be done again
With the changes I described, a mod like PHPBB SEO would be really much easier to install.
About the usefulness of SEO :
If you don't want to use SEO, don't use it. If you want to use it, do so.
I think having prettier URLs is a part of SEO, but there's much more: having good content, being known (backlinks...)
I'm not asking PHPBB to solve the problems caused by URL rewriting (like duplicate content), this is not PHPBB's role.
Let's switch the debate from "whether" to "how"
I posted an extensive list of advantages to clean URLs (that's the terminology), and refuted the counter-argument that they would necessarily leak private information (hint: referer hiding), in this discussion post.
What steps should be taken to mark this RFC ("whether to use clean URLs or not") as ACCEPTED, and move on to getting acceptance on implementation details?
What steps should be taken to mark this RFC ("whether to use clean URLs or not") as ACCEPTED, and move on to getting acceptance on implementation details?
- Erik Frèrejean
- Registered User
- Posts: 207
- Joined: Thu Oct 25, 2007 2:25 pm
- Location: surfnet
- Contact:
Re: Let's switch the debate from "whether" to "how"
First off al someone has to actually write an RFC, this is just an discussion topic . If you feel phpBB *needs* this you are of course free to create an RFC at the implementation you've got in mind and post that in the appropriate section so that the RCF can be discussed.dandv wrote:What steps should be taken to mark this RFC ("whether to use clean URLs or not") as ACCEPTED, and move on to getting acceptance on implementation details?
Available on .com
Support Toolkit developer
Support Toolkit developer
Re: SEO URLs
There have not been any objections from development team members in this topic, suggesting that the idea is not fundamentally unacceptable.
I note that titania does have clean/seo urls, implying at least someone on the phpbb teams wanted them and cared enough to implement them.
At the same time clean/seo urls is an enhancement, and boards are functional without them. Competing for development team's attention are bugs and features which are either more important (e.g. the hooks system) or more interesting to a particular developer.
In order for clean/seo urls to be incorporated into phpbb they have to be implemented first. They may be implemented by either a development team member or a contributor reading this topic. I'm going to assume we are talking about the second case as the first case simply involves waiting.
An implementation may be accepted or rejected. What might cause a clean/seo urls implementation to be rejected?
1. Performance - primarily extra database queries. Ideally there should be no extra database queries added. If the ideal cannot be achieved, and clean/seo urls can be turned off, when they are off there should not be any extra database queries.
2. Complexity - as in excessive complexity. The code should remain manageable, and server configuration should still be reasonable. It may be the case that changes elsewhere in phpbb may be needed to implement clean/seo urls without excessive complexity.
3. Requirement satisfaction - this is a question of how exactly urls will look, what happens to private forums, etc. We should not have a situation where after clean/seo urls are implemented some users will say "Great, but they don't support X" or "Great, but my board does Y and they don't work" and proceed to implement clean/seo urls differently.
4. Environment requirements - clean/seo urls should work on all platforms that phpbb supports as much as possible/practical.
Therefore, the first step in my opinion would be to go through this topic and any other relevant topics here and on phpbb.com forums and collect all requirements put forward by users, to determine if any of them conflict with each other such that no single solution will make everyone happy.
Once that is done, create an RFC with these requirements and an outline of an implementation. The RFC should include an explanation of how clean/seo urls will be recognized and generated, schema changes necessary and additional queries if any. It should enumerate ACP options that are necessary to satisfy all of the requirements put forward.
After creating the RFC you can start prototyping the implementation.
I note that titania does have clean/seo urls, implying at least someone on the phpbb teams wanted them and cared enough to implement them.
At the same time clean/seo urls is an enhancement, and boards are functional without them. Competing for development team's attention are bugs and features which are either more important (e.g. the hooks system) or more interesting to a particular developer.
In order for clean/seo urls to be incorporated into phpbb they have to be implemented first. They may be implemented by either a development team member or a contributor reading this topic. I'm going to assume we are talking about the second case as the first case simply involves waiting.
An implementation may be accepted or rejected. What might cause a clean/seo urls implementation to be rejected?
1. Performance - primarily extra database queries. Ideally there should be no extra database queries added. If the ideal cannot be achieved, and clean/seo urls can be turned off, when they are off there should not be any extra database queries.
2. Complexity - as in excessive complexity. The code should remain manageable, and server configuration should still be reasonable. It may be the case that changes elsewhere in phpbb may be needed to implement clean/seo urls without excessive complexity.
3. Requirement satisfaction - this is a question of how exactly urls will look, what happens to private forums, etc. We should not have a situation where after clean/seo urls are implemented some users will say "Great, but they don't support X" or "Great, but my board does Y and they don't work" and proceed to implement clean/seo urls differently.
4. Environment requirements - clean/seo urls should work on all platforms that phpbb supports as much as possible/practical.
Therefore, the first step in my opinion would be to go through this topic and any other relevant topics here and on phpbb.com forums and collect all requirements put forward by users, to determine if any of them conflict with each other such that no single solution will make everyone happy.
Once that is done, create an RFC with these requirements and an outline of an implementation. The RFC should include an explanation of how clean/seo urls will be recognized and generated, schema changes necessary and additional queries if any. It should enumerate ACP options that are necessary to satisfy all of the requirements put forward.
After creating the RFC you can start prototyping the implementation.
- DavidIQ
- Customisations Team Leader
- Posts: 1904
- Joined: Thu Mar 02, 2006 4:29 pm
- Location: Earth
- Contact:
Re: SEO URLs
The native URL Rewrite module in IIS7 makes doing this very easy and you can even import the .htaccess file that would be created to get this to work. It's what I've done with Titania on my test/dev server.Oleg wrote:4. Environment requirements - clean/seo urls should work on all platforms that phpbb supports as much as possible/practical.
Re: SEO URLs
I fully support clean URLs. Taking a more resource-oriented approach just makes sense.
We need to be careful though, as this will need to be forwards compatible. So if we make bad choices here, we can really shoot ourselves in the foot. So even if we *do* use something like `/posts/23`, that would be acceptable and better than what we have now, imo.
We need to be careful though, as this will need to be forwards compatible. So if we make bad choices here, we can really shoot ourselves in the foot. So even if we *do* use something like `/posts/23`, that would be acceptable and better than what we have now, imo.