TOPIC:

I guess there needs to be some support, like showing how to update/upgrade to a new version of JEM/Eventlist. a first release will probably not support migrating etc..

Hi people,.

what do you think about this:

Next week:
- put Eventlist v1.02 online a github and use it as start position.
It is based upon v1.01 and is supported under Joomla 1.6+
- people that want can find the files from there and test it and make contributes.
- put op a issue/bugtracker (is at github)

Then (probably 1 or 2 months)
- try to integrate a lot of the features of Eventlist v1.1 into this version (without new ACL support + multiple categories). ACL is to complicated for the moment and multiple categories can be for later.
- meanwhile test and make sure language files etc does exists.
- make sure the mailplugin & modules are working.
- update helpfiles
- make a helpfile for people that are using Eventlist version v1.1, since they are using a different tablestructure they will run into problems.
At this stage we should not add to many features but focus on the internal things.
- make a download sextion (website)
- make a FaQ section
- put up feature requests topic (there is one, but perhaps it can be done in another way)

// i don't think we should release versions until this has been finished but people ofcourse can download packages from Github when they want. And because we do not add enough new features we can't put it at JED as JEM. But we can call it JEM v2.5.0.1 development or something like that.


After 2 months we should have a good base
- we can then add new features
- use version numbers
- try to put it on JED
- look at the internal code of Eventlist
models/views and controllers do have to change sometime, cause we probably want to work with internal categories and Forms. But as the main goal is to bring a version at JED we should do this at a later stage. Or perhaps it would be a good thing to give this priority.


As we do want to have a version for Joomla 3+ the internal code has to be changed. This will ofcourse lead to adjustments but we should keep in mind that users of earlier versions have to upgrade easily and without to many hassle. At that point we can have a lot of versions (people that download testversion of github, little updates and "official" updates.)

I think we can have a good working version for Joomla 3 in November.
ofcourse it can be done a lot quicker but like this we do have some room.

I am preparing my answer! Not yet finished

- put Eventlist v1.02 online a github and use it as start position.
It is based upon v1.01 and is supported under Joomla 1.6+

ok, the old version should be possible to find and to download.
But it's important so say, that's the old version with no hacks and changes.
Perhaps there should be a notice of just found errors/problems.

- people that want can find the files from there and test it and make contributes.
- put op a issue/bugtracker (is at github)

ok

Then (probably 1 or 2 months)
- try to integrate a lot of the features of Eventlist v1.1 into this version (without new ACL support + multiple categories). ACL is to complicated for the moment and multiple categories can be for later.

why so late? Perhaps there should be also a (beta) version with the hacks included which were discussed in the posts of this (or earlier) forums.
This is often just a integration of EL 1.1
If not, it needs a revision of the hacks in the forum.
(Sometimes there was a long way with a lot of errors before finding the solution)

(without new ACL support + multiple categories)

without multiple categories ok, but I don't understand why not the ACL support which is important for joomla 2.5 and there are discussed solutions in the forum.

- meanwhile test and make sure language files etc does exists.
- make sure the mailplugin & modules are working.
- update helpfiles
- make a helpfile for people that are using Eventlist version v1.1, since they are using a different tablestructure they will run into problems.

ok

At this stage we should not add to many features but focus on the internal things.
- make a download section (website)
- make a FaQ section
- put up feature requests topic (there is one, but perhaps it can be done in another way)

ok

// i don't think we should release versions until this has been finished but people of course can download packages from Github when they want. And because we do not add enough new features we can't put it at JED as JEM.

I cannot understand this, because bringing together 1.02. and 1.1 makes something really new!

But we can call it JEM v2.5.0.1 development or something like that.

the goal must be a joomla 2.5 version with almost all joomla 2.5 features. The code has to be prepared for joomla 3.0 too (try to not use deprecated code!)

After 2 months we should have a good base
- we can then add new features
- use version numbers
- try to put it on JED
- look at the internal code of Eventlist
models/views and controllers do have to change sometime, cause we probably want to work with internal categories and Forms. But as the main goal is to bring a version at JED we should do this at a later stage. Or perhaps it would be a good thing to give this priority.

As we do want to have a version for Joomla 3+ the internal code has to be changed. This will ofcourse lead to adjustments but we should keep in mind that users of earlier versions have to upgrade easily and without to many hassle.

yes

I think we can have a good working version for Joomla 3 in November.
ofcourse it can be done a lot quicker but like this we do have some room.

ok

About ACL:
There are indeed some topics describing how to alter it, but this will lead to many adjustments. It has to be done but perhaps for later. At docs.joomla.org/Developing_a_Model-View-...onent/2.5/Adding_ACL there are some steps descibing how to (backend). Resulting in a different code for the toolbars, models, controllers, helper, tables.
That 's the backend, but frontend has to be altered too.

The gids can be altered back to aid's (more options).
the gid is at this moment looking for 3 options and showing groups. with aid it's more and is looking for the viewlevel. Leading to changing a lot of pages.( aid = AuthorizedViewLevels)

that said: we can also remove the group view of eventlist and use the internal ones. And that will also lead to adjustments.


I'm saying perhaps because there are other ways that can lead to rome.
Also, the whole thing has to be tested and make sure it works.


Eventlist v1.02 (clean package):
It's good to put the clean package at the website a a start, without any hacks etc. When uploading changes we can see what has been changed or altered.


Other:
There are a lot of things deprecated or outdated so there is much to be done. Also the code has to be like the standards of Joomla: developer.joomla.org/coding-standards.html

But as basis we can have code of the eventlist v1.1+eventlist v1.02 and then update/change stuff.


//edit
IT seems that the code in the frontend (in J2.5, com_content) is way different then it is at this moment so the whole thing has to change. Model+submodels. The access thing is also defined in another way. But for now it's probably alright to use the aid thing.

//edit2

why so late? Perhaps there should be also a (beta) version with the hacks included which were discussed in the posts of this (or earlier) forums.

There are indeed versions around with integrated stuff and perhaps people are willing to share their info. Actually i'm also having a version with stuff of v1.1 , but it can be that there is some stuff missing or that things have to be alterd in another way. Also the fieldnames, internalcode has to be cleaned. To speed up things i'm willing to post the changes and merge it in the clean version. This will be posted this week

The version includes: Ical, Calendar, excluded category's, attachments, recurrence, updated gmap code, new imagepack, changed category image upload (backend), altered settings view, waitinglist, changed css (the frontend does not look the way you used to know)

But be aware it's a test version and you can't update from Eventlist v1.02 as there are changed/added fieldnames. And something you have to keep in mind is that the code can be changed.

well, just a note..

i'm a little bit unsure what version to start with, the v1.02 would be understandable because it's running in Joomla 2.5 but there are a lot people that are using v1.1. // 1.1 is also more bugfixed.

The v1.1 has a install checker that looks what version is installed and will make adjustments. It also looks if v1.01 was installed. Since v1.02 is based at v1.01 that is not going to be a problem. So people with that kind of version can easily upgrade. Ofcourse we should use some Jem tables but that can be converted.// Adding stuff to the v1.02 will lead to the changes that have already been made in v1.1.

I've tried to modify some files of v1.1 and can say that it working partially. The multicat is working and did also try some changes with the accesslevels.

So at this moment i'm thinking about putting v1.1 at Github, just because it won't lead to problems with people that are using v1.1 and v1.02 version. In the attachments you're seeing a front page (with multicat) and a backend (with multicat). Actually the whole thing can be converted within 4 weeks.

Did had a lot of errors (image 3) but they can "easily" be resolved. And am planning to integrate the export/import view and altered settings view too.

So the plan is:
- start with v1.1 and convert it to Joomla 2.5 format.
- When that is done: integrate the new accesslevels and add some new features
- Unfortunately every page has to be altered

At first I was like "why now starting with v1.1"?

After reading your post, your argumentation has its points.

As I haven't had a look on the 1.1 codebase and therefore can't compare I can only make assumptions.

The point is, does it make more sense to adapt v1.1 to J2.5 or improve v1.02 to have the functionality of v1.1. Also, which strategy involves more work?

Using v1.1:
+ More functionality included
- Refactoring to get J2.5 (3.0) compatibility

Using v1.02:
+ J2.5 compatibility already
- Add missing functionality

You have to consider when using v1.1 the more funtionality that is included has to be reworked nonetheless to work with J2.5.

It's hard to decide, and unfortunately you seem to be the only one who is actually developing and working with the code.