Importing iCal URLs

[Celos]

Currently, imported events with URLs are saved as html entities (ie. <a href="URL">URL</a>) in the database. This seems very weird to me. Wouldn't it be much more prudent to save the data (ie. the URL) in the database and then build the link as requested on the front end? This would greatly increase compatibility with other components and also allow us to modify the link text as well.

On the importing side, the issue is with line 347 of the iCalImport.php file:

Code: Select all

$value = preg_replace('@(https?://([w-.]+)+(:d+)?(/([w/_.]*(?S+)?)?)?)@', '<a href="$1">$1</a>', $value);

[Tonyp]

Why would it cause issues? Do you mean when exporting into other calendar apps?

As it would technically require one less routine every time the page is loaded, this way it just outputs what's called rather than calling, preging then outputting.

Regards
Tiny

[Celos]

You need to get the URL from the DB anyway, so there is no difference between something like

Code: Select all

print $URL

and

Code: Select all

print '<a href="'.$URL.'"'>'.$URL.'</a>'

I'm not sure where preging comes into it.

This doesn't really create issues when showing the URL, but the other way would allow for more customizing in the templates. For example, showing text instead of the URL, like:

Code: Select all

'<a href="'.$URL.'"'>This is a link!</a>'

In my case, I'm using jEvents to manage multiple sources and need to have some of those sources redirect to their specific components. Without altering the above mentioned line, I could only get very ugly listings (full URLs instead of linked titles for example).

[carcam]

Hi Celos,
if I'm not too wrong, the pregging is to ensure that we get always full urls as for 99% ical imports, the URL will not be an internal link, but an external link. The point is that if you take a look at JEvents fields out of the box, there is no specific field for a link, so these URLs are stored in the extra info or the contact link (cannot remember exactly) field of the database. Storing it as a full HTML link makes them to be shown exactly as a link, otherwise they will be presented as simple text.

[Celos]

The URL is saved under "#__jevents_vevdetail" in the field "url", so it definitely has it's own field in the DB.

[carcam]

You are right, but it's not possible to edit that field from the event editor, although it's present in the layout defaults so I guess it has something to do with it.

Probably Geraint can give you a better answer.

[Geraint]

If this is important to you then change line 345 to read

Code: Select all

if (is_string($value) && $key!="UID" && $key!="URL"){

and keep a note of it for when you upgrade JEvents

[Celos]

Sorry for picking up an old subject, but I was unable to check back for a while.

It's not that much of an issue for me personally. I was already using a plugin to handle importing the ical files and I just changed it to also strip out the HTML around the URL (so as not to have an extra step to do every time I update something).

I'm just wondering if there's any specific reason to doing things this way? I'll give you a use case that made me aware of the issue:

Using multiple event components. For my client it's CiviCRM (a CRM targeted for civic-sector organisations) and jEvents. Since jEvents already has such well built front-end options, it's very tempting to use it to publish the CiviCRM events as well (since it itself has very few). However if you want to import the event to show on calendars and search results (but show the actual event info in the other component with it's registration etc fields), the only option available for templating is {{Title:TITLE}} - {{URL:URL}} or something of the like, resulting in ugly URLs.

Obviously it's not the concern of jEvents to handle these kinds of situations, but it'd be nice to have the freedom to be able to do that.

[Geraint]

With the club addons we import events from jomsocial and community builder using a special script that allows auto redirection to the source system from the event details. This would be a good option with CiviCRM too.

Creating a content plugin to redirect to the CiviCRM event detail page should be fairly straightforward.

[WORDtransfast]

It's really nice tips of iCal URL's. This discussion some of point is very useful for me thanks for sharing