Sneak Peek: OpenCart 1.5.0 *ALPHA*

Last time I check and it was some time ago and I don't really think they removed it dreamweaver handled php just fine. it showed it to you in the code view and put a little icon in the design view

If you're a visual person, that "feature" does you no good.

how would PHPTAL be any different?

PHPTAL shows sample data (if you're not connected to a db) so that you can see what the layout will actually look like when you're done. It makes a HUGE difference when you're designing. Besides, there are a lot of other HTML editors out there, besides Dreamweaver, that don't show even the PHP icon, so the page is pretty much blank.

Anything like this that would make designing templates easier is a good thing in my book.

Daniel wrote:I can use the current design if thats what people want. no mega menus.

Some of us without a million categories and who want our carts to look like the big, smart retailers even though we are small traders desperately want the mega-menus so PLEASE don't get rid of them as an option

If OC is going to be a top cart it needs to have that option. It's so obvious someone is using open source (Zen etc.) when you end up on a site where there's a mile long list of categories to the left. There's nothing wrong with that for those that like it but to move forward we need to be able to make stores to rival the big retailers and to remove that option is a step backward seeing as you've already made it possible.

I'm relatively new to open source but I thought part of the attraction was to be able to take a simple template that someone has kindly made and then tweak it to make it how you want. So by definition any default theme is going to be a bit boring and it's up to the users to make it interesting/exciting?

I think the mega menu is a great asset, i like it much better than the old one, a lot of new big e-comerce website use it.

Mega menus only suit some people. It would look pretty silly having a mega menu with only a couple of options in it. Thus, if it can't be made modular at this point (i.e. choosing which menu to display via admin) then it CANNOT be included. In future, sure, but not now at the expense of many users just because it's the 'new thing' in carts.

I really think mega-dropdowns should be an option, just because I've seen so many bad implementations of OpenCart. There are a lot of stores that need to change from dropdowns to mega-dropdowns.

However, if it isn't included, I'll hack it anyway

Not sure if that was in response to my post at all, but it should be included ONLY if it's an option that can easily be reverted to a regular drop-down.

gocreative wrote:Not sure if that was in response to my post at all, but it should be included ONLY if it's an option that can easily be reverted to a regular drop-down.

I wouldn't necessarily say that I would say it should only be included if it can be disabled. I see no reason why it has to be able to be turned into a regular dropdown. I'm sure there will be plenty of mods for that, but I agree there will be quite a few stores where a megamenu just doesn't make sense. I should be modular, and with all the new module positions I see no reason why it can't be.

But if it's just disabled then you're left with no menu at all, and the user has to customise the store just to get the 'standard' drop-down menu, which probably works for more users than a mega menu does (in my opinion).

I'm simply suggesting that the drop-down be retained for now, and in future releases when it's either possible to choose a menu without any hacking, or mega menus have been shown to work for more users than drop-downs, then the mega menu could be implemented.

It just doesn't make sense to change the menu now when it's unproven as to whether it's going to work for most users.

you do realize that there is no dropdown in the current version of opencart right? So it's not like it would be a step backwards or anything if someone turned it off. You can always use the regular category menu just like you do now.

In v1.5.0 there's a drop-down. That's what I'm referring to.

There is a flaw in the Order_Invoice setup since the Invoice was introduced!

When generating/printing and Invoice it uses the Order-date as Invoice-date, this is incorrect.
The Invoice-date, in most cases, will never be the Order-date.
According to my Tax agent this is not compliant with the law but when granting warranty it could mean that because the Invoice-date = Order-date customers could lose up to weeks when having a 1year or 2year warranty.

While "we" are still developing 1.5 this should be fixed as well.

I agree! I think the mega menu is a great asset!

i2Paq wrote:There is a flaw in the Order_Invoice setup since the Invoice was introduced!

When generating/printing and Invoice it uses the Order-date as Invoice-date, this is incorrect.
The Invoice-date, in most cases, will never be the Order-date.
According to my Tax agent this is not compliant with the law but when granting warranty it could mean that because the Invoice-date = Order-date customers could lose up to weeks when having a 1year or 2year warranty.

While "we" are still developing 1.5 this should be fixed as well.

Seems like something you should put in a bug report

Qphoria wrote:

i2Paq wrote:There is a flaw in the Order_Invoice setup since the Invoice was introduced!

When generating/printing and Invoice it uses the Order-date as Invoice-date, this is incorrect.
The Invoice-date, in most cases, will never be the Order-date.
According to my Tax agent this is not compliant with the law but when granting warranty it could mean that because the Invoice-date = Order-date customers could lose up to weeks when having a 1year or 2year warranty.

While "we" are still developing 1.5 this should be fixed as well.

Seems like something you should put in a bug report

Done, completely forgotten about the BUG reporter.

just out of curiosity what would be the invoice date? As mentioned before here in the US it's really a receipt and the current implementation would be correct because it shows the day you paid. what do you use in EU the date you ship?

Xsecrets wrote:just out of curiosity what would be the invoice date? As mentioned before here in the US it's really a receipt and the current implementation would be correct because it shows the day you paid. what do you use in EU the date you ship?

No, the date the the invoice is generated (mostly the shipping-date as well).

This is a must to have.

Are we gonna see the code soon?

dbstr wrote:Are we gonna see the code soon?

This should be asked Q whether he minds to righclick the preview folder, zip and upload somewhere we can download
May be it can cheer us, since i 'm bit bored with the conversation. Page 13 and still talk about mega menu

So many improvements. I feel sorry for the devs reading through this thread so I'll just list my two favourite improvements. That new mega-menu and the new column/module/layout handling.

I'll also register my eagerness to get my hands on the alpha code

Is the 'Shipping by SubTotal' module going to make it into 1.5.0? I'd really like to see that as part of the core again.