OpenCart Community

Qphoria wrote: Perhaps reports should just be considered "extensions" and we can just add it as a new extension type.

I could get with this with one exception they need to be able to populate a menu. I don't think you should make the user go through the extensions page to view the reports. Actually not being able to dynamically change the menus has been a big gripe of mine for a while. I'm really liking how you can do it now with vqmod, but until it matures and gets included we can't count on users having it installed.

Xsecrets wrote:

Qphoria wrote: Perhaps reports should just be considered "extensions" and we can just add it as a new extension type.

I could get with this with one exception they need to be able to populate a menu. I don't think you should make the user go through the extensions page to view the reports. Actually not being able to dynamically change the menus has been a big gripe of mine for a while. I'm really liking how you can do it now with vqmod, but until it matures and gets included we can't count on users having it installed.

Its a big gripe for everyone, that is why I want to make it an extension. The reports would be just like feeds for the backend. Additionally, "Tools" will become an extension, for things like backups, import/export, package managers, etc. Instead of using the current module area to "fake" it. Or instead of trying to make it a new controller and hack the menu. Technically the word "Extension" is what we want... to "Extend" the cart with custom addons, and the existing Extension system will allow us to do it without core edits, which is what we want.. we've just not been using it to its full potential.

For reports, you'd just click "Reports" and similar to the way you have a list of modules, you'd have a list of available reports that community members could make. And they'd be drop-in just like the other extensions.

For tools, you'd click "Tools" and it would show a list of tools. Currently for my CSV Export/Import I made it a "module" but a module requires the catalog side to have a catalog/controller/module file.. so I fake it with an empty class and dummy index() function that does nothing. That is really how the excel import/export should be done too and the whole menu bother would be history. But still, a proper "Tools" area would not require that catalog side fake module but still have the dynamic approach of a drop-in system.

Damn near everything should be made into an extension

Damn near everything should be made into an extension

That goes back to post of mine about 2 months ago.
opencart as a framework (no not the phpro / CI part). The more modular the cart is the easier it will be too just drop in a new section. The vqmod (it seems, haven't used it yet) does that but in a different way.

My original idea was drop and replace system. So, changing out the default reports system would be no problem.
Also, users could build their own cart with parts (like lego blocks) and go from there.

@ bitchin'
To reduce that (like I've said in the past) is to have a line of communication.
Showing up every so often and saying things are moving forward only builds higher expectations. So, when things go slow people are like WTF.
I really think that most people can deal with a "hey, taking the daughter to the zoo" or "it's her birthday". It's ok to be human, but getting a simple update really doesn't take that much time.

communication ...

SapporoGuy wrote: @ bitchin'
To reduce that (like I've said in the past) is to have a line of communication.
Showing up every so often and saying things are moving forward only builds higher expectations. So, when things go slow people are like WTF.

I already covered that scenario.. i said when I do communicate, people bitch that the communique was not what they wanted to hear and complain about the contradicting dates.

Qphoria wrote:

SapporoGuy wrote: @ bitchin'
To reduce that (like I've said in the past) is to have a line of communication.
Showing up every so often and saying things are moving forward only builds higher expectations. So, when things go slow people are like WTF.

I already covered that scenario.. i said when I do communicate, people bitch that the communique was not what they wanted to hear and complain about the contradicting dates.

Yes but that's not really the appropriate solution. The appropriate solution is actually to indicate what features will be in each version, and don't provide any firm dates. If the Road Map was being used correctly then users could look at that to see what has been completed and what hasn't. Therefore if 10 features were listed for the next release and nine were marked as 'Complete', then a) you don't have to keep providing updates on progress and b) users can roughly see when the next version is likely to be available. It wouldn't completely solve the problem (people will always want exact dates) but I think it would greatly improve OpenCart's communication and reduce your workload.

Also covered that too in my last post

oneilldesign wrote:

Qphoria wrote:

SapporoGuy wrote: @ bitchin'
To reduce that (like I've said in the past) is to have a line of communication.
Showing up every so often and saying things are moving forward only builds higher expectations. So, when things go slow people are like WTF.

I already covered that scenario.. i said when I do communicate, people bitch that the communique was not what they wanted to hear and complain about the contradicting dates.

Yes but that's not really the appropriate solution. The appropriate solution is actually to indicate what features will be in each version, and don't provide any firm dates. If the Road Map was being used correctly then users could look at that to see what has been completed and what hasn't. Therefore if 10 features were listed for the next release and nine were marked as 'Complete', then a) you don't have to keep providing updates on progress and b) users can roughly see when the next version is likely to be available. It wouldn't completely solve the problem (people will always want exact dates) but I think it would greatly improve OpenCart's communication and reduce your workload.

yes I'm with you on set the features and let them determine the date. I want no part of what some other people are wanting set a date and drop features if you can make them in on time. Just makes no sense for an open source project to run that way.

Administrators/Moderators - I also feel, as Q has indicated previously, this topic has run its course and should be closed. Most of what has been discussed in this topic has had no relevance to the topic - Progress towards 1.5.0. Only Daniel can advise on this, as Q has said, only Daniel is developing this version at present. The current discussion should be seperated into a seperate topic: Management of Opencart - The Future.

Therefore I vote that this topic is either closed or restricted purely to administrators with something of value to contribute to the 'Progress towards 1.5.0', this includes not posting fictious or unrealistic timescales that with all the best intentions seem never to be met.

Qphoria wrote:Its a big gripe for everyone, that is why I want to make it an extension. The reports would be just like feeds for the backend. Additionally, "Tools" will become an extension, for things like backups, import/export, package managers, etc. Instead of using the current module area to "fake" it. Or instead of trying to make it a new controller and hack the menu. Technically the word "Extension" is what we want... to "Extend" the cart with custom addons, and the existing Extension system will allow us to do it without core edits, which is what we want.. we've just not been using it to its full potential.

For reports, you'd just click "Reports" and similar to the way you have a list of modules, you'd have a list of available reports that community members could make. And they'd be drop-in just like the other extensions.

For tools, you'd click "Tools" and it would show a list of tools. Currently for my CSV Export/Import I made it a "module" but a module requires the catalog side to have a catalog/controller/module file.. so I fake it with an empty class and dummy index() function that does nothing. That is really how the excel import/export should be done too and the whole menu bother would be history. But still, a proper "Tools" area would not require that catalog side fake module but still have the dynamic approach of a drop-in system.

Damn near everything should be made into an extension

I completely agree on this!

Qphoria wrote:I think this thread is nearing its end...

By that, I hope you mean that 1.5.Beta is about to be released

Qphoria wrote:The simple facts are:
Will 1.5.0 have more changes than originally mentioneda few months ago: YES
Will 1.5.0 take longer than originally thought: YES
Can we predict the future: NO
Should we update the roadmap more often: YES
Should we manage the features between versions better: YES
Should we update the community more info: Well...
- When we give a release date we are applauded...
- When we say we are going to add even cooler features than originally planned we are applauded...
- When we say the release date is going to be delayed because of the new features.. we are bitched at
- When we realize that additional bits and pieces must be added NOW rather than LATER, to avoid upgrade issues... we are applauded
- When we say those changes will also delay the release... we are bitched at.
- When Daniel gives a release date 2 months ago... he is applauded.
- When I give an update to the community about a new date based on changes... people say "well daniel said blah blah..." and bitch about the contradiction, when really I'm just trying to give updates that people claim to want.

It's like people want to be updated but then don't want to hear the reality of the situation.

I think you are right - many people, when they say they just want an update, actually just want an update that they want...we have all dealt with people who say they just want an answer, but actually want an answer that they want and bitch when the answer is not to their liking...

That being said, I think there has been a communication disconnect....addition of features is communicated in one place, dates in another, and not everyone can always connect the dots...it might have been easier sailing if the original roadmap had been transparent along with target dates, and in the updates you had said, listen guys, we decided to add A, B and C, so we'll take another 5 weeks...or hey guys, the core changes are taking longer than anticipated, the new estimated release is 7 more weeks than originally planned...

Either way, I think it will help if there an actual roadmap...somewhat like a GANTT, complete with dependencies etc...and it is updated every week or so....some people will still bitch or ask questions about release dates....but then i2Paq and XSecrets will be more than happy to refer them to the roadmap, I'd imagine....so you won't be taken away from any productive time to answer "stupid" questions...

Qphoria wrote:At this point it just comes down to Daniel having time to get to it all, even with 2 developers available, he is changing so much of the core that that needs to be done first before other parts can be done so he has the ball and I can't really help to adjust other things until that is done, and that wouldn't matter if we had 10 developers.

When 1.5.0 comes out we will be looking for at least one more developer for a specific targeted area:
- a Reports Developer. This person will work only on new official reports. This is pulled directly from the existing data in the database so no changes in the rest of the cart should affect this much and it should be very easily manageable on its own. We technically need to make reports work like extensions first, so they are standalone like the existing extensions and dynamically read into the system on a reports page. Perhaps reports should just be considered "extensions" and we can just add it as a new extension type.

I do second the notion of handling everything like an extention - I deal with a lot of software vendors at work and I've found that the best ones are those that handle everything via APIs...even if everything is made by the same company! This creates a lot of flexibility for integrations with 3rd parties, as well as a very modular development ...even overall better quality as specialists can be roped in to develop specific parts...

That said, a lot of the most important "extensions" should continue to be handled and supported by the core team...as updates have a habit of breaking extensions...and there could be many extensions whose breaking would be unacceptable....

I don't know much about the hook system that you are creating, but from end user perspective, if one can search and install extensions from admin panel a la Wordpress or SMF, that would be a huge huge plus....

Finally, regarding reporting developer...Fido-X has already created a pretty high quality product and he is working on improving it...if he has the time, I'd say he makes an excellent addition to the team...

P.S. As a final note...Q, if you aren't taking family time at the moment, module & theme developers would surely appreciate some sort of developer documentation...especially with regards to coming changes....Gallery 3 had over 50 modules ready to plug in by the time it was released...imagine how cool it would be if it's the same for OC 1.5.0

Qphoria wrote: For reports, you'd just click "Reports" and similar to the way you have a list of modules, you'd have a list of available reports that community members could make. And they'd be drop-in just like the other extensions.

For tools, you'd click "Tools" and it would show a list of tools. Currently for my CSV Export/Import I made it a "module" but a module requires the catalog side to have a catalog/controller/module file.. so I fake it with an empty class and dummy index() function that does nothing. That is really how the excel import/export should be done too and the whole menu bother would be history. But still, a proper "Tools" area would not require that catalog side fake module but still have the dynamic approach of a drop-in system.

I look forward to the new release, and I am happy to use the new 'Tools' area for the upcoming Export/Import tool. The same is true for the 'Reports'. I have done loads of different reports for different customers, and hope to release some of them for the new Opencart 1.5.0.

I am also in the process of designing a generic addon extensions manager for Opencart which will be integrated into the Opencart backend, which will make use of the vqmod, and which will include a resolution feature for conflicting addons.

At this point, may I also say a big Thank You to all the Opencart developers for all your hard work to make this project a success.

I really like the idea of making tools/reports as extension. How difficult would it be to automtically read the language file and add them as variables? Currently we need to we need to map wach string in the Controller classes like In my opinion, this will save lot of duplicate code if you could simply read the language files are add them as variable. The controller just needs to load it.

Just a thought.

cartpro wrote:I really like the idea of making tools/reports as extension. How difficult would it be to automtically read the language file and add them as variables? Currently we need to we need to map wach string in the Controller classes like

Code: Select all

$this->data['key'] = $this->language->get('key');

In my opinion, this will save lot of duplicate code if you could simply read the language files are add them as variable. The controller just needs to load it.

Just a thought.

This capability is actually already in the current versions it's just not used yet. If you search the forums you will see some discussions on how to do it. I believe they said they were going to try to get the code converted over to working this way for 1.5.0, but if not I'm sure one of the early point releases will be fully converted. As for mod makers they can already do it if they want.

That's a good news. Let me search on the forum.

The tools and reports thing just came to me in a dream the other day.. I've actually already got it working mostly in 1.4.9.3.. took about 10 mins. .I'll try to get it into 1.5.0 or 1.5.1 the latest.. its mostly cosmetic change for the current reports and existing backup tool, but I'd rather get it in sooner than later to make it the new standard way.

Qphoria wrote:The tools and reports thing just came to me in a dream the other day.. I've actually already got it working mostly in 1.4.9.3.. took about 10 mins. .I'll try to get it into 1.5.0 or 1.5.1 the latest.. its mostly cosmetic change for the current reports and existing backup tool, but I'd rather get it in sooner than later to make it the new standard way.

reports-tools-extension.jpg

yeah I like the idea, and it will allow you to have settings for reports which will open up some new avenues as well. My big question is once you upload and enable a report is it then going to automatically show up in the reports menu or will you have to access it through the extensions section. same thing for tools. I think it's a great way to handle it, but it does need to add to the main menu to make it easier for end users to find what they are looking for.

reports menu is gone.. its all under extensions->reports
Once you upload it, it will simply appear there.

Qphoria wrote:reports menu is gone.. its all under extensions->reports
Once you upload it, it will simply appear there.

I rather see that for reports and other "tools" there would be a separate structure instead of putting all in Extensions.

This will get the Extension part overcrowded.

Qphoria wrote:reports menu is gone.. its all under extensions->reports
Once you upload it, it will simply appear there.

yeah I would really like to see the menu stay. One of the things you hear alot from people who choose opencart is because the admin is easy to use and intuitive, moving reports under extensions would detract from that. I really don't understand the aversion to making the menu's dynamic.

Xsecrets wrote:

Qphoria wrote:reports menu is gone.. its all under extensions->reports
Once you upload it, it will simply appear there.

yeah I would really like to see the menu stay. One of the things you hear alot from people who choose opencart is because the admin is easy to use and intuitive, moving reports under extensions would detract from that. I really don't understand the aversion to making the menu's dynamic.

Correct, Reports, Backup and other Tools will be much more used then Shipment, Payment and other Extensions under Extensions. Once you have set your payment, shipment and other modules you never go there.

Qphoria, like your CMS Categories module, you have put it under Catalogies, where the Information Pages already are.
That is a logical place, do the same for Reports etc. etc.