Thread

The relative URL issue is nothing to ddo with the base_url config item, it is purely a TinyMCE configuration issue. I know which items need to be played with so tomorrow I will work out the correct combination. shouldn’t take more than 10 minutes to get that working when I find the time. 😊

Highlighting selected pages is something I previously added in but took out as it was pretty dodgy. If you can think of a good solution then go for it. My only plan would be to add an extra field that has simplified regular expressions (similar to the routes syntax: ie /news/:any) and if they match then send $link->is_active or something similar.

What do people think on that? It could of course be handled automatically for most of the link types (modules, pages, etc) and would only need to be entered for those adding in their own URI links.

As far as the release of v0.9.7 its hard to say. There are quite a few things going on at the moment and I would not like to rush this next release if possible. We are running out of numbers before the big 1.0! :lol:

The relative URL issue is nothing to ddo with the base_url config item, it is purely a TinyMCE configuration issue.

I’m interested in how you’ll address the problem with TinyMCE generated paths/urls.
I’ve also opened a thread about this without a definitve (so far) solution.

Take a look at the TinyMCE configuration documentation under the URL sub-heading.

Looking closer at that previous issue with rel urls it proved not to be the answer and relative_url seems to be on a per instance basis when tinymce is initialised.

i was thinking along the lines of a syntax such as “controller=:value” which can then be chained together with “|” as a separator to get more specific behaviour. For example for highlighting the homepage (by default) it would be something in the order of “default=yes|controller=pages|slug=home” and optionally allow regex on urls (relative to the base path) for more advanced users in the order of “(news/*)|help” which would require “regexmatch=yes”

This would require two fields to be added for each entry in navigation_links and one field to be added to the navigation_groups table to specify parameters for the matcher.

I really think you are overcomplicating things by listing parameters. The URL is the only thing people will see and even that is a bit much.

If we have a field that has a simplified regex then we can easily slap a GUI over the top of it at a later date. Creating all sorts of crazy new syntax is just making life more difficult for everyone.

Could you PM me your solution to the TinyMCE fix? I have a standardized way of creating TinyMCE instances so I can configure the “wysiwyg-advanced” instance to handle URL’s with those config options. That will fix it for all larger TinyMCE boxes in news, pages, products, etc.

Take a look at the TinyMCE configuration documentation under the URL sub-heading.

I was not referring to the way Tinymce handles paths/urls, but to the paths in the (TinyMCE or plain textarea) HTML elements (img, a, etc), instead.

Very true, means that it would be easier to code/more flexible. I guess I’ll have to beef up on regex to get started with that task. In most cases autogenerating the regex from the link destination would be adequate in that regard.

What was the feature set that you supported with your implementation?

The feature set i’m aiming for is having the ability to enable it for a specific navigation group and being able to define the default active link if no expressions match (which wouldn’t normally happen).

Take a look at the TinyMCE configuration documentation under the URL sub-heading.

I was not referring to the way Tinymce handles paths/urls, but to the paths in the (TinyMCE or plain textarea) HTML elements (img, a, etc), instead.

What is the difference? The paths in the HTML elements ARE handled by TinyMCE…

Yes they are, but i was talking about how these paths can be preserved when your filesystem changes.
see my thread on the issue

It is a little trickier but the configuration options are still the same!

Set the document base root to your base URL. Then tell it to remove the host name and keep files relative.

I’ll let you know when its done on PyroCMS so you can see what im blathering on about.

Thank you Phil,
but I know how to configure TinyMCE for proper paths handling.
My thread in on a different issue.

Anyway, ignoring your very confusing thread, PyroCMS v0.9.7-pre now has relative URL’s working fine.

Remaining tickets until we release v0.9.7:

Fix the freakin captchas - Me
Dashboard information - ignitedcoding
User specific permissions - Turv

Not hearing much from ignitedcoding and Turv right now, hope they can submit something soon as I had v0.9.7 down to be released yesterday.

We are getting there anyway. 😊

Anyway, ignoring your very confusing thread, PyroCMS v0.9.7-pre now has relative URL’s working fine.

The problem has been outlined and defined, while a definitive solution has not been provided yet.
Take the time to read the whole thread

We are getting there anyway. 😊

Keep up the good work!

I meant to say, “whatever the hell it is you are trying to achieve with relative URL’s and WYSIWYG’s, we have resolved our issue”. I have no idea what your problem is but it seems it is different to ours, so that is great.

Also, I need people to start giving feedback on v0.9.7-pre. It seems pretty stable but I don’t want to have to release v0.9.7.1 after a few hours/days in the wild. Let’s make sure! 😊

i’m not seeing a tagged v0.9.7-pre on the github page.

i grabbed the latest commit, put it on, the installer works great, currently creating a new page.

One bug i found when creating a new page, i screwed up on the ‘slug’, i put ‘test.html’ it took me back to the new page i am creating, told me i screwed up on the ‘slug’, and i found that what i had put into the editor ‘this is a test page’ got turned into ‘this is a test page’, which meant that what appeared on my page itself was that.

Seems like it isn’t putting it back as the html source.