Ryan Nielson
Active member
I just bought the add-on so I'm still experimenting... I guess I haven't noticed it yet.That already exists.
I just bought the add-on so I'm still experimenting... I guess I haven't noticed it yet.That already exists.
All addresses are searched using Google Maps. It needs to be able to find a valid result.While doing additional testing I noticed some weird behavior that doesn't apply to all finnish addresses. For example when creating an event with address Vaakatie, Vantaa (or another example: Mannerheimintie, Helsinki), thread title location uses event name. What makes it weird is that some others addresses do work just fine, i.e.: Kaivokatu, Helsinki.
If I change thread location format to state, then it gets the correct city data for those problematic ones (...and in turn adds unnecessary data for others.)
I'm guessing this is soemthing to do with how the data is stored at google maps, but hopefully there is something that could be done to fix it.
Yes, but it does find a valid result at least when looking at the resulting map/address data via the frontendAll addresses are searched using Google Maps. It needs to be able to find a valid result.
Do you have a link?@Jaxel We've recently started using this plugin on our website, when we create a Bi-weekly re-occuring event, all the dates will show up on a weekly view, but it seems in the monthly view we are only seeing ever other occurrence is there a fix for this?
Unfortunately, its whatever Google gives us.Yes, but it does find a valid result at least when looking at the resulting map/address data via the frontend
Working one (Kaivokatu 12, Helsinki) :
View attachment 120905
(Kaivokatu 1, Helsinki doesn't work)
Nonworking one (Mannerheimintie 12, Helsinki) :
View attachment 120906
I already told you how timezones work... and as for "normal layout" for event threads, I still have no idea what you are talking about.i guess you're not going to add the timezone adjusting in the event itself, and a normal layout for event threads or tell me how to do it myself.
What specific event is having the issue?
What specific event is having the issue?
Confirmed... working on figuring out whats wrong.http://stratics.com/calendar/2016.1/month
If you look on at the Event on Jan. 11th 2016, on the Monthly Calendar view, it should have repeated on Jan. 25th 2016 as well. It shows an upcoming occurrence on the 25th when you view the event on the 11th, but it doesn't show that upcoming occurrence on the monthly calendar.
Can you go into: EWRatendo2/Model/Occurs.php and remove line #390:http://stratics.com/calendar/2016.1/month
If you look on at the Event on Jan. 11th 2016, on the Monthly Calendar view, it should have repeated on Jan. 25th 2016 as well. It shows an upcoming occurrence on the 25th when you view the event on the 11th, but it doesn't show that upcoming occurrence on the monthly calendar.
GROUP BY EWRatendo2_events.event_id
That appears to have fixed the issue, at the moment I haven't noticed any new issues, but if they do appear I'll make sure to let you know.Can you go into: EWRatendo2/Model/Occurs.php and remove line #390:
Tell me if that fixes the issue, and also tell me if it causes other issues.Code:GROUP BY EWRatendo2_events.event_id
yes you told me how you think they should work, but i would rather have a option to edit the timezone everywhere. so it always displays the time in the user's timezone. everywhere. at calendar, at event, at occurences. Exept for the topic description where i post the time in my timezone.I already told you how timezones work... and as for "normal layout" for event threads, I still have no idea what you are talking about.
What specific event is having the issue?
Umm... I fail to see the issue in any of these screenshots. When you promote a thread to an article in XenPorta, it moves the OP text to the top of the page, above ALL other content. This is by design; for an article, the article text is the most important. This will not be changing. If you dont want a thread to act like an article, then don't use the article layout; this can be disabled on a PER-ARTICLE basis.Here are the 2 screenshots again to explain about the "normal layout" issue.
With topic:
http://i.imgur.com/DS0sFtX.png
Without topic:
http://i.imgur.com/rQIa4cC.png
I would like, when i create a event with a topic, to show it in the layout of this picture: http://i.imgur.com/rQIa4cC.png
But its not possible unless i probaly globally disable that layout for articles. i dont want that. i only want to disable it for creating events, so the post/topic/article i create when making a event, looks like this layout: http://i.imgur.com/rQIa4cC.png and not like this: http://i.imgur.com/DS0sFtX.png
- BUG FIX: This update fixes a major bug that prevents events from showing more than one occurrence per monthly view. For instance, if you had an event set to repeat every week, this bug, which was introduced in the last update, would only show the first occurrence of the event, and not the others.
- BUG FIX: Fixed an issue where if RSVPs were disabled for an event, it would still show "0 Going" on the occurrence list.
- Added an option to reverse the order of...
Ok i found it after digging. But this is a bit cumbersome. My steps to make it work is:Umm... I fail to see the issue in any of these screenshots. When you promote a thread to an article in XenPorta, it moves the OP text to the top of the page, above ALL other content. This is by design; for an article, the article text is the most important. This will not be changing. If you dont want a thread to act like an article, then don't use the article layout; this can be disabled on a PER-ARTICLE basis.
View attachment 121700
We use essential cookies to make this site work, and optional cookies to enhance your experience.