Seems best to let things be ... especially since no one is complaining about missing zones.Quote:
Originally Posted by DrByte
Printable View
Seems best to let things be ... especially since no one is complaining about missing zones.Quote:
Originally Posted by DrByte
They've just been merged :)Quote:
Originally Posted by lat9
Quote:
Originally Posted by Dayo
Fair enough. Still, thanks for engaging in the discussion and offering to contribute.Quote:
Originally Posted by Dayo
Perhaps preparing a plugin/addon that contains your proposed updates would be another option ... and we could get some community feedback, a crowd-sourced testing of sorts?
Wherever zen_image_submit() is used, the CSS Buttons logic will output appropriate classes for that purpose. Catalog-side that's pretty much universal. Admin-side will get it with upcoming revisions.Quote:
Originally Posted by dw08gm
Was tryng to work on something related to attributes being displayed in the proper sequence and came across something I thought may be mysql server dependent, but on further testing does not appear to be so simple of a .
Discovery was in includes/modules/attributes.php and may be an issue in other files if in the same format.
When the sort order for option names is identified in product info as by sort order followed by name, then in the file, the sort order becomes: order by LPAD(popt.products_options_sort_order,11,"0")
But, when this is run perhaps the first time, then the data is presented as desired in sort order followed by option name order, but if that page is reloaded or the query performed again then the sort order is lost to return to being in the order of the options_id.. I thought that I had posted about this once before a long while back, and maybe the "solution" still stands that nothing need be done, but I thought I would bring it to light again.
This is fine if a sort order is applied to the option name, but when the sort order is 0 for all option names (or the same) the result is by option name id not by option name.
I then went to phpmyadmin and entered the exact query as created for the Execute, and got the same result, but the query was also slightly modified to add a space after each piece of information in the LPAD statement. When I then refed that query in, the result came back correctly sequenced (the first time)...
When I then went back to the attributes.php file and added the same space after each comma, then the attributes were presented in the correct sequence once correctly and then subsequent tries while on the same page were again presented incorrectly...
So yes it seems odd that it sorts properly one time but then subsequently incorrectly, but also the statement in admin is to sort by sort order and option name or to sort by option name. The sort provided to the query though only enforces either sort order or option name not both.
So my recommendation after all this is to change the LPAD statement here (and in other places entered the same) to be like:
Server OS: Linux 3.2.61-grsec-modsignCode:if (PRODUCTS_OPTIONS_SORT_ORDER == '0') {
$options_order_by= ' order by LPAD(popt.products_options_sort_order, 11, "0"), popt.products_options_name';
} else {
$options_order_by= ' order by popt.products_options_name';
}
Database: MySQL 5.6.25-log
HTTP Server: Apache
PHP Version: 5.6.10 (Zend: 2.6.0)
PHP Memory Limit: 128M
PHP File Uploads: On
Max Size: 20M
PHP Safe Mode: Off
POST Max Size: 20M
Let me know if there is any specific or other data needed to reproduce this issue...
Even after accessing tools->Store Manager->Update All Products' Attribute Sort Orders
to match Option Value Default Sort Orders, the data still appears not in the sequence described by the admin option for sorting option names... Evidence also seen in the attributes controller.. Looks like either the admin description is incorrect, or the code at some point along the way is missing something to provide the response described... I found several other locations where the sort order of option_names was generated the same as provided in includes/modules/attributes.php Would be nice to have the full functionality described by adding the sort of products_options_name instead of removing the text of the option selection. :/
Uh-oh! The admin-level configure.php file for ZC1.5.5 was reworked to discontinue the use of the ENABLE_SSL_ADMIN setting -- unfortunately, no one told
- admin/includes/functions/html_output.php (lines 21 and 44)
- admin/includes/init_includes/init_general_funcs.php (line 59)
- admin/includes/init_includes/init_sessions.php (line 23)
EDITED BY AJEH:
also referenced: /includes/functions/html_output.php
In the interim, the defined_paths.php file defines HTTPS_SERVER so as to minimize the need to hack out a bunch of code. We've deferred the bigger change to v160 where lots of improvements are made to how those defines are used.Quote:
Originally Posted by lat9
Small suggestion: admin/customers.php lines 1245, 1265 - "pwreset" should be "pwdreset" to match "pwdresetconfirm" and TEXT_PWDRESET_INTRO (line 306 and 1247-1248).
Hi Finally had a bit of time to start looking at the new version. Sorry if any of these are duplicated I have tried to read through the previous messages.
On a brand new install I have a few issues/ suggestions
1) "Main /includes/configure.php file does not exist (isn't readable) or is not writeable" error is clickable but no extra help provided. Same for admin (do you want empty files in place?)
2) if you copy over the config template file from zc_install errormessage appears "Probems with database connection based on the entries in your current configure.php
2005:Unknown MySQL server host '%%_DB_SERVER_%%' (2)" this links to itself again.
3)Database setup. Should you add note to this page to say that you need to create a database before completing the fields. (I know that you should know this but is it better to cover all bases). the errormessage if you don't is "There are some problems. Problems with Database Connection 1049:Unknown database 'zencart'.
Also you recommend not using root but do not test for its use.
Hope this is useful if duplicated please ignore.
Thanks!Quote:
Originally Posted by brittainmark
Will look into the help text for that.Quote:
Originally Posted by brittainmark
The correct "source" to copy from is the /includes/dist-configure.php file ... which is why it's in that folder.Quote:
Originally Posted by brittainmark
Will mention that further in the help text.
Good point.Quote:
Originally Posted by brittainmark
These are all mentioned in the /docs/Implementation_Guide-v155.pdf file, but we all know nobody reads written docs despite the time it takes to write them. The on-screen help text can use some updates. Thanks for pointing these out!
Correct. On live production sites, root should not be used. But on offline localhost dev sites sometimes it's quite desirable, hence we're not preventing that.Quote:
Originally Posted by brittainmark