Remove url elements

[mastafu]

I would love to,be able to change url.

From domain.com/event/events-name/date
to domain.com/events-name or domain.com/categories-name/events-name

This is something very, very important and I am wondering why for so many years You have it like you have it right now. There should be at least way to change url, like ie. K2 for Joomla, biggest and best CCK.

Short urls are better for SEO then long urls.
So url which is domain.com/events/category/category-name is just plain waste of url space 😉
it should be
domain.com/category/category-name

If your plugin is used as a base for webpage then domain.com/events/event-name is a kind of problematic. Especially for multi lang webpages!

To sort this problem out, the best would be to give option to remove category, events and event altogether.

[Barry]

Hi mastafu,

From domain.com/event/events-name/date
to domain.com/events-name

Ordinarily you should only see the date if it is an instance of a recurring event. What sort of method would you prefer to use to identify the actual event date if it was not passed via the URL (given that all instances of a recurring event share the same slug)?

[mastafu]

I would like to be able to remove /event/ and change order to domain/date/event-name
then it makes sense …

My webpage is based on your plugin. It is a big web calendar and so, on the main page I have events listed (using option to publish events in posts loop) and that allows me to list events on the address domain.com. Now when you click on the event, you are going to the events content and address changes to domain.com/event/date/event-date and then you can list all events (like on the main page) but with the address domain.com/events

That is just inconsistent and can lead to duplicate content, because there is no canonical rel added.

So domain.com/events is a good solution for webpage which can list events when you go to the menu element /events/ but when you want all events listed on the main page then it is not good solution for url management.

[Barry]

OK, I see what you’re saying.

Right now however the plugin simply isn’t built in such a way that it can readily facilitate this. If you are at home working with the WordPress rewrite rules system then you could probably tweak it into behaving as you would like.

I’m surprised to hear you say there is no canonical URL, however, can you point to an example of this?

[mastafu]

Because You closed my other topic about urls yesterday I want to add just one more example … How url should be constructed, based on WordPress example 🙂

At the top of the page http://codex.wordpress.org/Using_Permalinks, you fill find this …

http://example.com/2012/post-name/
or
http://example.com/2012/12/30/post-name

Please don’t use pretty words, saying how much you appreciate users support, which leads to nothing … just to closing the topic, and being happy not to have to spend extra time on fixing things. This is not how support works for paying customers.

[Barry]

Mastafu: again, I still don’t agree. That doesn’t mean I’m right and you’re wrong – and it doesn’t mean I don’t understand or appreciate your suggestions and ideas.

/%year%/%monthnum%/%day%/%postname%/

When that particular permalink structure is in use with a WordPress blog every single post (belonging to the regular post post type) uses it. If we took a similar approach then every single event URL would be a quite lengthy affair, unnecessarily so – and I believe you yourself commented here or in another thread on how a “good URL” is as short as possible.

WordPress offers numerous ways to structure permalinks. The fact that this is one of the ways they offer by default for date-based permalinks is interesting but doesn’t in itself mean it is some sort of best practice that should be used across the board. Maybe it is an SEO win – or maybe it introduced only for performance reasons – however it’s been around for a long while and if we were to adopt a similar approach we would want a concise argument to be laid out for doing so.

Please don’t use pretty words, saying how much you appreciate users support, which leads to nothing … just to closing the topic, and being happy not to have to spend extra time on fixing things. This is not how support works for paying customers.

I’m sorry you feel that way, because we do appreciate new ideas and suggestions for improvement. That doesn’t mean, however, that every time someone proposes a change we will accept it – nor should we.

As I suggested when I closed the thread, if this is something you feel strongly about please post a feature request and detail your arguments as to why your way would be an improvement. The advantage of this is that other customers can then show their approval or otherwise comment on the idea, which is useful information for us: you clearly feel quite passionately about URL structure but it may be others have opposing views or other concerns about any changes here.

Returning to the issue you opened this thread for, from my last reply:

I’m surprised to hear you say there is no canonical URL, however, can you point to an example of this?

Are you able to elaborate on this at all? Where are they missing and are you seeing this with a default theme or something else?

[mastafu]

The way You respond and the way you treat people with all this voting and not fixing things when they sound resonable (like 99,99% of url structures are like the one I sugest) puts me off. Unfortunatelly I need to finish this project, which is in advnaced stage, but future projects will be based on plugins, where developers DO listen and react.

[Barry]

You know, “fixing things” implies there is a bug here or something that’s fundamentally wrong. Really what you want is a change and, in your eyes, an improvement – but it’s not a change that we frequently see being requested. That doesn’t by any means we’re not interested or that we won’t ever do it – just that we want sound reasoning and some more feedback before doing so since this is a change that would affect all of our customers and users, not just you. I’m sorry that approach is problematic for you.

I also don’t feel that asking you to post a feature request over on our UserVoice page is too onerous a task when all is said and done – especially when you feel so strongly about this – but it’s entirely up to you. It’s an avenue that’s open to you when and if you want to follow it.

[Kelly]

Hi, mastafu. As it’s been more than a couple of weeks since your last post, I’m going to close this thread. Please feel free to open a new one if you choose to pursue this further.

Thanks! 🙂

[Support Droid]

This topic has not been active for quite some time and will now be closed.

If you still need assistance please simply open a new topic (linking to this one if necessary)
and one of the team will be only too happy to help.

[Author]

Posts