I know this may be the wrong place to ask this; has v155 been released yet? and a shot in to the future, V160 dates?
Printable View
I know this may be the wrong place to ask this; has v155 been released yet? and a shot in to the future, V160 dates?
The v155 beta is still in progress, and we hope to release it in January 2016.Quote:
Originally Posted by adb34
You can see information about release announcements and roadmap posts in this section of the forum: News and Announcements
php 5.6.4Quote:
Originally Posted by DrByte
mysql 5.6.22
Thanks mateQuote:
Originally Posted by DrByte
Thanks Anne, for all your work.
Thank you, I appreciate your support ;)Quote:
Originally Posted by lucidlee
Thanks,
Anne
Anne,
Are you planning on a thread for the Responsive Classic? I have some thoughts and questions but, I don't want to clutter this thread with stylesheet queries.
THANX
Anne has started a support thread at https://www.zen-cart.com/showthread....onsive+ClassicQuote:
Originally Posted by dbltoe
Has the problem with text attributes not showing up as "required" even if the box has been clicked in Attributes Controller been addressed in 1.5.5 code?
It wasn't in the version I am testing, but can't remember what day I downloaded the code from github for sure, so thought I would ask.
See Scott's post below:
https://www.thatsoftwareguy.com/blog...t-not-working/
I am not seeing that in v1.5.5 ... I was testing with the demo products for:
Per letter - required
and it appears to work fine ... :lookaroun
Keep in mind this is triggered by Add-Ons that are not written correctly and delete those needed settings in Zen Cart which breaks the TEXT requiredQuote:
Originally Posted by stellarweb
Quote:
Originally Posted by stellarweb
Quote:
Originally Posted by Ajeh
In a way it was corrected a version or two ago (confirmed to be corrected in ZC 1.5.3 and 1.5.4, I don't/never have installed ZC 1.5.2 and ZC 1.5.1 still had "that" issue)... The "pertinent" data is now stored in a different configuration location. Those values are no longer kept in gID=0 and are no longer "lost" because of incorrectly formatted SQL (BTW, was guilty at least once of providing something that caused this... Lesson learned... :) )Quote:
Originally Posted by Ajeh
As far as "addressed", I have a feeling that if in an upgrade, the values were previously deleted (non-existent) that they are not recreated, but I'm starting a rumor by saying that as I haven't looked through the install/upgrade code to validate that the value is created/recreated in the appropriate location if missing upon upgrade. Wouldn't surprise me though if it were "restored" if absent in an upgrade from 1.5.1 or below to at least 1.5.3.
NOTE: the configuration_group_id was changed from 0 to 6 ... and, providing they exist, they will be updated ...
I simply added a option name with TEXT, then in attributes controller clicked the box on the bottom right that says Attribute required for text "yes" and it did not work (would allow checkout without the text field having anything in it) until I ran the SQL script in Scott's post.
Guess there is more than one way to skin a cat! But still wonder if maybe I am not "getting" what Attribute required for text box is all about...
Quote:
Originally Posted by Ajeh
In phpMyAdmin, search the configuration table for the configuration_keys:
PRODUCTS_OPTIONS_TYPE_SELECT
UPLOAD_PREFIX
TEXT_PREFIX
Do all 3 of these come up?
The TEXT required means if a Product with a TEXT attribute is attempted to be added *without* the Text actually filled in, it will not be added to the shopping cart and you will get a warning saying fill it in ...
If the TEXT attribute is marked as required and this warning does not come up when trying to add the Product to the cart without filling in the Text, then there is a problem to be addressed ...
Yes on all three showing up in phpMyAdmin
The 1.5.5 is pretty much a vanilla cart - and the text attribute was marked required, but was still able to add the product to the cart without the text field filled in. Once I installed Scott's sql - it worked properly
Same thing happened with my 1.5.4 installation - but that one does have a few mods installed.
I will go do a BRAND SPANKING NEW install with today's code and see if it does the same thing and report back. This 1.5.5 install was from 1/14/16 - so is a week old.
Quote:
Originally Posted by Ajeh
That doesn't really make sense on the v1.5.5 ...
A plain vanilla v1.5.5 works fine ...
Are you really saying a Zen Cart v1.5.5 with a database from an older version of Zen Cart that you ran the Upgrader on? :lookaroun
When in phpMyAdmin, and you searched for the configuration table for the configuration_keys:
PRODUCTS_OPTIONS_TYPE_SELECT
UPLOAD_PREFIX
TEXT_PREFIX
Did you find 1 of each or many of each?
There was only one of each and yes, it was an upgrade in the sense that I brought over only the product tables from an older version then ran ZC_install again once they were brought over. That must have been what caused the problem.
I just did a fresh install and it worked properly ..... except that it would not let me do anything in the attributes controller if I had only added a text attribute under option name and there were no other option names listed. It gave me the following error: Warning: No Option Values have been defined
Once I added a "fictitious" option name and added an option value, then I was able to apply the text attribute to the product and marking it required worked.
Just to test... I then went back and deleted the "extra" option name / value so that I was left again with only a text option I had set up, and again got the same error - it would not let me add the text attribute without first setting up a fictitious option name/value that was not TEXT
Quote:
Originally Posted by Ajeh
Had those been there, there would have been a slightly different setting as the upgrader fo v155 would have run:
You should run that in the Tools ... Install SQL patches .. to bring them up to date on the configuration_group_id to switch from 0 to 6 ...Code:UPDATE configuration set configuration_group_id = 6 where configuration_key in ('PRODUCTS_OPTIONS_TYPE_SELECT', 'UPLOAD_PREFIX', 'TEXT_PREFIX');
I know this is pretty petty but one thing I have always struggled with is styling the "display price". :lookaroun
Maybe it would be possible to add a span in functions_prices.php, I alter this file for this reason on every template or client site I have ever designed or re-designed.
line 255:
PHP Code:if ($product_check->fields['product_is_free'] == '1') {
$show_normal_price = '<s>' . $currencies->display_price($display_normal_price, zen_get_tax_rate($product_check->fields['products_tax_class_id'])) . '</s>';
} else {
$show_normal_price = $currencies->display_price($display_normal_price, zen_get_tax_rate($product_check->fields['products_tax_class_id']));
}
perhaps something like:
PHP Code:if ($product_check->fields['product_is_free'] == '1') {
$show_normal_price = '<span class="productFreePrice"><s>' . $currencies->display_price($display_normal_price, zen_get_tax_rate($product_check->fields['products_tax_class_id'])) . '</s></span>';
} else {
$show_normal_price = '<span class="productBasePrice">' . $currencies->display_price($display_normal_price, zen_get_tax_rate($product_check->fields['products_tax_class_id'])) . '</span>';
}
Ok thanks Linda - will keep that in my arsenal of upgrade things not to forget! lol
However.... we are still left with the core / vanilla 1.5.5 issue of not being allowed to add a text attribute to a product without first creating a "fake" non/text option name and value.
This happens when there are NO option names or values entered - which is the core settings. Guessing someone needs to revise that - otherwise people are not going to have a clue that they need to create that "fake" attribute in order to get a text attribute to work. This could be as simple as to just to include a "sample" option name and value in the core SQL. That would solve the issue as long as no one deletes that... has the page empty of attributes, then tries to enter a text attribute. :shocking:
Quote:
Originally Posted by Ajeh
I think you lost me ...Quote:
Originally Posted by stellarweb
What is the "fake" attribute that you are referring to?
Plain / vanilla / fresh install of 1.5.5 code from yesterday without any demo products ....
Went to Catalog>Option Name Manager>Created an Option name of "enter your text here" with an option type of "text"
Went to Catalog>Attributes Controller>So I could apply this text option to a product and I get the following error at the top of the screen "Warning: No Option Values have been defined"
So... I cannot add a text option to my product right out of the box.
BUT... if I go to Catalog>Option Name Manager> and create a "fake" option name, and then create a value that is NOT a text option (eg checkbox, radio, etc) THEN when I go to Attributes controller, I can add my text box to my product.
That is why I am saying that if a "fake" or "example" attribute were added to the core sql, then this would not happen unless someone goes in and removes the "example" one.
I have no clue if other versions other than 1.5.5 are this way. I only tested 1.5.5
Hope that is clearer than mud!
PS - Linda let me know if you need access to my install and I will pm it to you.
Quote:
Originally Posted by Ajeh
Done. https://github.com/zencart/zencart/pull/795Quote:
Originally Posted by rbarbour
I am not sure if this is the right place, in case I apologize.
Why isn't still available the grid layout for product listing, as to give more flexibility, and being a common feature on other carts, and quite requested?
In the few carts I installed Zen Cart it was not such a hard task to add the plugin, hence IMHO making it native shouldn't be overlooked.
When you first go to the Catalog ... Option Name Manager and Created an Option name of "enter your text here" with an option type of "text" ... did you have any other Option Names before you tried to make it?Quote:
Originally Posted by stellarweb
Thanks for the test database. I found a way to log some more detailed errors, and it flagged up an error related to your customers table.Quote:
Originally Posted by dbltoe
Also using Navicat I discovered that you have a single customer record in your particular DB whose customers_dob is set to '0000-00-00 00:00:00' (which is invalid in modern MySQL versions) instead of '0001-01-01 00:00:00'. Changing that lets the installer properly update the schema in the customers table for the v153 changes, and lets the installer proceed.
I can't find where customers_dob was ever set to zeros by default, so I'm reluctant to start adding SQL to the upgrade to deal with userland data problems.
From the couple of times identified above, it looks like a blank database (tables created to support ZC 1.5.5 created) with no attributes of any type added to table(s) before adding the one text option_name which does not populate the option_values table.Quote:
Originally Posted by Ajeh
Looking at admin/attributes_controller.php lines 15-24 option related data is identified present in series.. First for option_names, then by option_values. Option_value search does not account for option_names existing that also do not have dependent option_values (text and file uploads)... An independent "search" would in some way help with this to accept/consider that the option_names that came back are those that don't have option values... Not well said:
If no option_names: error message.
If no option_values:
Cycle through the option_names, if any option_name is not text or file upload, then error like currently, otherwise carry on to next check...
And actually, even that is incomplete, because there is no test of whether the option_values relate to the option_names... But...
Thinking a little further on that... Perhaps a new function that receives pertinent data and returns whether the option_name is expected to have an option_value or nnot with a notifier included for others that may develop/have developed an option_name that inherently doesn't carry an option_value... Of course can always go the reverse and identify if the option_name does carry an option_value, either would resolve that "issue".
This second one though, would require the contributor to include a step to add the option_name to the "yes have values" list as compared to the less frequent "no don't have values" list which pretty much is an abnormality... :/
Created pull request #799 to potentially address the issue identified by stellarweb of beginning with a blank database (no attributes either option name or option value) and adding only an option name that does not have a corresponding option value required/expected. IE. Text attribute or file upload... This is unfortunately untested as a "thought experiment". Added a notifier to allow developers to "chime in" on option names that have been created that do not have option value assignments. All other added option_names would be expected to have an option value. (I considered this the more "conservative" action.)
I have no clue as to how the date was changed but, you are right, it should not have been what it was.Quote:
Originally Posted by DrByte
Could you share your Navicat method for finding this? I've had no luck in doing so myself. Of course, a sort in the customer table works but, I've found this in more than one database. It would be nice to have a shortcut for doing this since several of our current sites transferred in. it would be prudent for me to check a little closer before updating.
THANX
I just used the sort.Quote:
Originally Posted by dbltoe
Yeah, knew that. Just thought you knew some way of using search.
I suppose a simple SQL query would suffice, like "select * from customers where customers_dob = '0000-00-00 00:00:00' ".Quote:
Originally Posted by dbltoe
But I usually avoid that since I'm intending to fix the bad data at the same time, so a couple clicks gets me there faster than typing out a query and guessing the field name, etc.
Hi , just saw that 1.5.5 is coming up.
I'm currently updating from 1.51 to 54, but still in a early stage.
Should I proceed with 1.54, or wait a litle while ? I mean, it's a matter of a couple of weeks or a long way to go ?
Thanks
personally i would start the upgrade. the differences between 1.5.4 and 1.5.5 will probably be far less that the task of upgrading to 1.5.4 from 1.5.1.Quote:
Originally Posted by mesnitu
my understanding is that 1.5.5 is close.... but the last 5% is always the hardest, and i do not think the ZC team will commit to a specific release date... until it is released.
just my 2c.
Yeah, I can understand that, I was just trying my luck :) You never knowQuote:
Originally Posted by carlwhat
But I think I'll wait. it's not only zencart, but all the modules, after a while, things get complex
admin_page_registration
id missing. I added it a long time ago, can't remember why...maybe just because all the others have one!
Quote:
<div>
<label for="pageParams"><?php echo TEXT_PAGE_PARAMS ?></label>
<?php echo zen_draw_input_field('page_params', $page_params, ' id="pageParams"');?>
<span><?php echo TEXT_EXAMPLE_PAGE_PARAMS ?></span>
</div>
<div>
<label for="menuKey"><?php echo TEXT_MENU_KEY ?></label>
<?php echo zen_draw_pull_down_menu('menu_key', $menu_options, $menu_key) ?>
</div>
Quote:
<label for="pageParams"><?php echo TEXT_PAGE_PARAMS ?></label>
<?php echo zen_draw_input_field('page_params', $page_params, ' id="pageParams"');?>
<span><?php echo TEXT_EXAMPLE_PAGE_PARAMS ?></span>
</div>
<div>
<label for="menuKey"><?php echo TEXT_MENU_KEY ?></label>
<?php echo zen_draw_pull_down_menu('menu_key', $menu_options, $menu_key, ' id="menuKey"') //steve added id ?>
</div>
Did another clean install today for testing and see this is still an issue and think it would be confusing for a new installer....
Quote:
Originally Posted by stellarweb
The issue below in quotes is still present with latest version tested today, vanilla DB, no mods, no demo products installed.
After adding a Text option Name.... then clicking Attribute Controller or going to product list and clicking the "A" by the product
goes to /options_values_manager.php
Warning: No Option Values have been defined
HTTP Server: Apache
PHP Version: 5.4.32 (Zend: 2.4.0)
PHP File Uploads: On
Upload Max Size: 2M
PHP Memory Limit: 128M
POST Max Size: 180M
Database: MySQL 5.5.48-cll
Database Host: localhost (127.0.0.1)
Database Date: 02/11/2016 15:22:54
Database Data Size: 211 kB
Database Index Size: 398 kB
MySQL Slow Query Log Status: On
MySQL Slow Query Log File: /var/lib/mysql/server-slow.log
MySQL Mode: (None set)
Zen Cart 1.5.5
Database Patch Level: 1.5.5
v1.5.5 [2016-02-11 15:08:46] (New Installation-v155)
v1.5.5 [2016-02-11 15:08:46] (New Installation-v155)
Quote:
Originally Posted by stellarweb
https://github.com/zencart/zencart/pull/799 has now been merged, which should address this.Quote:
Originally Posted by stellarweb
Fixed .Quote:
Originally Posted by torvista
Works perfectly!!
Quote:
Originally Posted by DrByte
Hi Guys,
Not sure if it a bug or if it's the way the category editor, product editor and page editor is meant to behave in the new version but I thought I'd mention it. The eror happen with the text in the files or when adding your own content with HTML tags and as plain text with paragraphs.
Better safe then sorry huh? :)
This is a straight out of the zip installation and setup, with no edits, no mods, and no addons installed.
------------------------------------------------------------------
Formatting of text via the Define Pages Editor function
------------------------------------------------------------------
EG: Open the Shipping file vis the Define Pages Editor function in tools ... the text looks like normal.
<p><strong>Shipping Information</strong></p>
<p>We haven't updated this page yet. Please use the Contact Us form to let us know!</p>
When it is saved
All the HTML tags are converted and display on the shipping page:
<p><strong>Shipping Information</strong></p> <p>We haven't updated this page yet. Please use the Contact Us form to let us know!</p>
The tags have been converted to:
<p><strong>Shipping Information</strong></p>
<p>We haven't updated this page yet. Please use the Contact Us form to let us know!</p>
And when it is formatted in plain text with paragraphs like:
Shipping Information
We haven't updated this page yet. Please use the Contact Us form to let us know!
The page text looks like one long paragraph:
Conditions of Use Sample Text We haven't updated this page yet. Please use the Contact Us form to let us know!
Please feel free to contact if you need further clarification. :)
Kind Regards
Les :)
This should be fixed now. https://github.com/zencart/zencart/pull/825Quote:
Originally Posted by stellarweb
Les this is exactly the same problem I'm having. I cannot get HTML text to display like HTML, even if I copy, say, define_checkout_success.php from my running 1.5.4 site, they just come up exactly as you say.Quote:
Originally Posted by webmanstudios
I'm running zen-cart on Windows Server 2012 R2, MySQL 5.6 and PHP 5.6.17. I've deleted the database several times and tried different creation options but ended up with my preferred option of UTF8_general_ci but this problem still perists.
Anyone got any idea about what is happening here?
Thanks, Andy
hard coded text
Quote:
if (IS_ADMIN_FLAG === true && (MODULE_PAYMENT_MONEYORDER_PAYTO == 'the Store Owner/Website Name' || MODULE_PAYMENT_MONEYORDER_PAYTO == '')) $this->title .= '<span class="alert"> (not configured - needs pay-to)</span>';
It's a bug. We're working on a fix for our over-zealous input cleaner-upper :)Quote:
Originally Posted by webmanstudios
The fix for it is still in-progress, but initial code is at: https://github.com/zencart/zencart/pull/828 (and has been merged, but also followed-up with a few other commits subsequently).
I'm encountering a lot of difficulties in getting OzPost shipping module to work in v155.
Obvious signs of failure is the repeatable effect of wiping out checkbox options if they are changed, leading to an inability of the module to provide shipping estimates - in fact the options don't appear at all in the shopping cart or at checkout.
Before Update showing checked boxes
Attachment 16043
After Update showing all checkboxes have been cleared
Attachment 16042
Note that the radio button which was changed from No to Yes shows yes after updating as expected
Examination of the Configuration table shows that the checkboxes are represented in OzPost records as arrays and are set using this function, stored in the set function field for that record e.g.:
In v154 the Ozpost code works just fine but in v155 since at least January 13 it has been failing.Code:zen_cfg_select_multioption(array(
'Skippy Post Air',
'Skippy Post Air Insured',
'Skippy Post Air with Tracking',
'Skippy Post Air with Tracking and Insurance',
'Skippy Post Air +Proof of postage',
'Skippy Post Air Insured +Proof of postage',
'Skippy Post Air with Tracking +Proof of postage',
'Skippy Post Air with Tracking and Insurance +Proof of postage' ),
Logs created by an OzPost configuration update event show lots of entries like this:
The first line of the PHP Warning suggests that the sanitiser is being troubled by an array that it wasn't expecting.Code:[16-Feb-2016 00:14:08 Australia/Sydney] PHP Warning: htmlspecialchars() expects parameter 1 to be string, array given in /zc_154/nimrod/includes/classes/AdminRequestSanitizer.php on line 314
[16-Feb-2016 00:14:08 Australia/Sydney] PHP Stack trace:
[16-Feb-2016 00:14:08 Australia/Sydney] PHP 1. {main}() /zc_1545/nimrod/modules.php:0
[16-Feb-2016 00:14:08 Australia/Sydney] PHP 2. require() /zc_1545/nimrod/modules.php:10
[16-Feb-2016 00:14:08 Australia/Sydney] PHP 3. require() /zc_1545/nimrod/includes/application_top.php:171
[16-Feb-2016 00:14:08 Australia/Sydney] PHP 4. require() /zc_1545/includes/autoload_func.php:48
[16-Feb-2016 00:14:08 Australia/Sydney] PHP 5. AdminRequestSanitizer->runSanitizers() /zc_154/nimrod/includes/init_includes/init_sanitize.php:226
[16-Feb-2016 00:14:08 Australia/Sydney] PHP 6. AdminRequestSanitizer->processBuiltIn() /zc_154/nimrod/includes/classes/AdminRequestSanitizer.php:75
[16-Feb-2016 00:14:08 Australia/Sydney] PHP 7. call_user_func:{/zc_1545/nimrod/includes/classes/AdminRequestSanitizer.php:90}() /zc_154/nimrod/includes/classes/AdminRequestSanitizer.php:90
[16-Feb-2016 00:14:08 Australia/Sydney] PHP 8. AdminRequestSanitizer->filterStrictSanitizeValues() /zc_154/nimrod/includes/classes/AdminRequestSanitizer.php:90
[16-Feb-2016 00:14:08 Australia/Sydney] PHP 9. htmlspecialchars() /zc_1545/nimrod/includes/classes/AdminRequestSanitizer.php:314
[16-Feb-2016 00:14:08 Australia/Sydney] Request URI: /nimrod/modules.php?set=shipping&module=ozpost&action=save, IP address: fe80::226:8ff:fede:e711
#1 htmlspecialchars() called at [/zc_154/nimrod/includes/classes/AdminRequestSanitizer.php:314]
#2 AdminRequestSanitizer->filterStrictSanitizeValues()
#3 call_user_func() called at [/zc_154/nimrod/includes/classes/AdminRequestSanitizer.php:90]
#4 AdminRequestSanitizer->processBuiltIn() called at [/zc_1545/nimrod/includes/classes/AdminRequestSanitizer.php:75]
#5 AdminRequestSanitizer->runSanitizers() called at [/zc_1545/nimrod/includes/init_includes/init_sanitize.php:226]
#6 require(/zc_154/nimrod/includes/init_includes/init_sanitize.php) called at [/zc_154/includes/autoload_func.php:48]
#7 require(/zc_154/includes/autoload_func.php) called at [/zc_1545/nimrod/includes/application_top.php:171]
#8 require(/zc_154/nimrod/includes/application_top.php) called at [/zc_154/nimrod/modules.php:10]
Have I found the smoking gun?
I should add that this warning was generated by the v155 beta that contains the #828 fix.
All tests have been conducted on vanilla copies of v154 with only sample data and OzPost added, then upgrading to v155
Testing environment: MAMP Pro, PHP Version: 5.6.10 (Zend: 2.6.0), MySQL 5.5.42
Notes to devs.Quote:
Originally Posted by lucidlee
I've not been able to replicate this fault. It doesn't to exist in the v155 that I tested with at the end of December.
I've not tried it with any of the later updates, partly because I've only recently been informed of the problem, partly because I've been pretty busy working on updates for another system, but mainly because this aspect of the ozpost code hasn't had any changes for several years now (other than adding new carrier/methods and removing the obsolete ones.).
I suspect that it is due to the input cleaner upper (expecting strings only, and failing when confronted with an array). The array data isn't unique to ozpost though, and I've asked the OP to see if the same issue exists with any of the other shipping modules (awaiting a reply)
The Skippy post example provided by the OP is just one of many similar code snippets used by the ozpost module and apparently all are effected.
The text/numeric inputs are (apparently) saving just fine. The OP has identified the problem to relating to the radio button multi select. The ozpost config options also include single select dropdown menus. I am awaiting feedback from the OP to see if these are also affected (I suspect that they won't be).
If it weren't for the Dr's comment about "it's a bug due to an overzealous input cleaner upper", even though it was in regards to a different issue " I'd be downloading the latest code to do my own debugging, but I can't help thinking that the two are related, so on that basis I'm inclined to just sit back for a wee bit longer and hoping it'll all be ok (again) when v155 is officially released. In fact it is due to this kind of unexpected issue that I've been holding the next ozpost update for... Just in case I do need to tweak/change something for compatibility.
My questions at the moment are, am I just being wishful that the problem is with zen rather than ozpost? Is the input cleaner upper bug likely to affect the multi select options, or do I need to investigate this further myself?
Cheers
RodG
I'm 90% certain it's part of the bug we're still working on.
I have uploaded the new 1.5.5 beta copied the new files to a test file set and used the zc_install.
The result is what cen be seen by the screen captures I made.
It tells that the db was correctly updated to 1.5.3 but then it says I need to update it because I am on 1.5.2!
kind of confusing and no way to proceed with the upgrade.
Please help if possible.
ThanksAttachment 16045Attachment 16046
It's very possible that you've triggered a database error during the upgrade. Look in the /logs/ folder for zcInstall-DEBUG.log files, to find out the details.Quote:
Originally Posted by enzo-ita
Dreaded Admin SuperUserName/Password after db update error.
Install 1.5.5 in subfolder of our sandbox domain which is on a different server/same host.
1st run, all looked good except no access to Admin after completion. Admin configure created, but zero contents (empty file).
2nd run of zc-install, all functioned as expected. Looks fine with demo data.
Drop all db tables
Import backup 1.5.4 database
Run zc_install as Upgrade. Don't remember any errors.
Attempt admin login using 1.5.4 superuser credentials. No good.
Used this https://www.zen-cart.com/content.php...28i-lost-it%29
AND that worked. Admin access using Admin/admin.
However, none of the admin logins from the imported database will function.
Sandbox: MariaDB 10.0.23/mySQL5.5.5
Live: mySQL 5.6.29
PHP both servers: 5.5.30
i have found a small bug in v1.5.4 which seems to carry over to v1.5.5. not sure if it is worthy of a fix, but i thought i would share it.
in includes/init_includes/init_sanitize.php, on line 72, there is an unset($GLOBALS[$key]).
if someone tries passing over a "db" variable in the URL, it would unset the $db and then zen-cart would generate some error logs, as now one could no longer access the database.
perhaps the dev team is already aware of this behavior, and chosen to do nothing about it. perhaps it has already been covered in the forums before (and if so, i do apologize). perhaps it might be worth wild to have a white-list of variables that can not be manipulated by GET variables. i'm not really sure what the way to go would be...
best.
Are you still working on this?Quote:
Originally Posted by DrByte
The reason for asking is that I've just downloaded a fresh .zip from github, and I've *not* been able to reproduce
lucidlee's error/problem.
This suggests that the problem, if with the zencart/ozpost code was ok on Jan3rd (my previous install date), then got busted with the version lucidlee downloaded, and has been fixed again with the most recent update (Feb 15)
OR, if this isn't the case, then lucidlee still has a problem specific to lucidee,
So, I thought I should ask before going any further.
Cheers
RodG
still working on it
includes/modules/payment/paypal.php
Should not this function be get_error like all the other payment modules? I don't find anything using it.PHP Code:/**
* Used to display error message details
*
* @return boolean
*/
function output_error() {
return false;
}
Could more use be made of the new HTML5 types in input forms? e.g. type="email", type="tel", type="number", etc.
This would make an enormous difference to users on phones and would compliment the new responsive theme. On the iPhone (at least) these type settings cause a modified keyboard to display which makes it easier to enter email addresses, phone numbers and numbers respectively.
Sorry if this is a feature request and not a bug report.
Andy
v155 does this alreadyQuote:
Originally Posted by amayze
Sorry. I thought I'd checked this, but I have just done so now and it quite clearly does do it already as you say. My apologies.Quote:
Originally Posted by DrByte
Though having tried to create a new customer, I've found a bit of a visual ambiguity for the required field indicator on iPhone screens.
The first picture is of the New Customer section of the Login screen, showing the *s for required fields at the end of the fields, which is clear enough.
Attachment 16050
The second picture shows the same screen on an iPhone 5.
Attachment 16051
Unfortunately the *s end up on a line by themselves and it's not totally clear which field they apply to. Would it be clearer (and possible) to put them after the text label?
i.e.
First Name: *
[ Text Field ]
Last Name: *
[Text Field ]
etc.
Andy
@amayze, there's another forum through which you can post your template-related issue: https://www.zen-cart.com/showthread....Support-Thread
Thanks for answering.Quote:
Originally Posted by DrByte
No I did not trigger any database error.
The problem was simply in the admin table that was a old (1.5.1) version. I managed to delete the table and upload one coming from a 1.5.3 clean install and it did work perfectly.
Ciao from Italy.
enzo
Quote:
Originally Posted by lucidlee
Quote:
Originally Posted by RodG
Quote:
Originally Posted by DrByte
Quote:
Originally Posted by carlwhat
Fixed code has been merged into the v155 branch. Should be working fine now.Quote:
Originally Posted by RodG
There was a bug earlier this week where the admin config file might be 0 bytes under certain circumstances. That's been fixed now.Quote:
Originally Posted by RixStix
Haven't been able to recreate this sort of situation in any tests in the last couple weeks of importing old databases. Stumped about what's uniquely causing that on your end.Quote:
Originally Posted by RixStix
Hi,
I am testing 1.5.5 and found that on an android smartphone, using chrome, the menu with the three lines does not appear. It comes out regularly with firefox and opera for android and also in the "internet browser" usually found as default in a android samsung phone.
I did a small search but did not find mentions of this bug reported in this thread.
Ciao from Itlay.
enzo
I've tested the latest v155beta (downloaded 16_02_20 11.49pm AEDST) on the following setups:
1. virgin v1.5.5 with OzPost 3.6.5 and 4.0.2 and had no problems with OzPost functionality
2. virgin v1.5.4 with OzPost 4.0.2 then upgraded to v1.5.5 and had no problems with OzPost functionality
3. clone of production v1.5.4 system containing a number of other modules including OzPost 4.0.2 and had no problems with OzPost functionality
All running under the same MAMP Pro setup as previously described, so I support Dr Byte's assertion. The mystery remains as to why I repeatedly encountered the problem in the first place when the developer couldn't reproduce it despite heroic efforts on his part. Moot now.
TESTING REQUEST:
We've recently accepted a community code submission to integrate Bootstrap into the Admin in order to make the Admin menu navigation more friendly on mobiles/tablets. It also makes the admin home page easier to read on mobiles because of its responsive stacking of data boxes.
This isn't a wholesale implementation of Bootstrap, as that would be a huge overhaul of the admin and would delay this release another several months and make upgrades even more complicated. We'll leave that overhaul for a later release :)
We'd appreciate some feedback on any issues that might have been caused by this change. Please test the following:
a) admin navigation, on mobiles, tablets, desktops (at standard screen sizes)
b) footer display, particularly on: 1) pages with lots of data, 2) on reports, and 3) when printing the pages you most commonly print.
Using a 155 version downloaded at around 2:20 pm EST today.
In the admin-console, with a two-language store (English and Spanish), there's a white-on-white component so that the selected language (while selected in the HTML) doesn't display the associated text. The <select> tag and its <option> tags are properly formed; it's an issue with the CSS (that I'm having trouble finding).
The overall admin-page padding seems to be "off" (or non-existent). Take a look at the Customers->Orders page, for example:wacko::
- The buttons use the default colors.
- The text butts up to end-of-screen on both the right and left
- There is no padding/margin for the orders-status-history table
- There is no padding between the order totals text/value pairs
Proceeding on to the products' entry. I've got customers who use styling in their product names:
... which results in a preview display of that name as:Code:<span style="font-family: Roboto;">#</span>Product Name
If it wasn't bad enough that the HTML is now displayed as (er) HTML, the processing has removed characters from the HTML itself! Clicking the "back" button from the preview keeps the malformed HTML.Code:<span stylfont-family: Roboto;">#</span>Product Name
That's part of the admin sanitization improvements to mitigate against XSS.Quote:
Originally Posted by lat9
Why exactly are they putting [span]s in the product name? Is this just to insert some icon?
I can't seem to recreate this. Not finding any white-on-white.Quote:
Originally Posted by lat9
Padding issues addressed here: https://github.com/zencart/zencart/pull/848/files?w=0Quote:
Originally Posted by lat9
They're using the <span> to have a different font for the hash-symbol.Quote:
Originally Posted by DrByte
The problem shows up also in the demo products (Test Examples->Test Three), as that product "demonstrates" the use of HTML tags in a product's name (uses <strong> and <br />). The only difference there is that the processing doesn't mangle the HTML associated with the product like it did the <span> with HTML attributes).
To me, it seems like the mitigation is removing a feature that's been around from the get-go.
That helped with the padding; the order-navigation buttons on the top of Customers->Orders still "leave a lot to be desired".Quote:
Originally Posted by DrByte
The language-changer in the header's upper-left corner. It's only visible when multiple languages are defined in the store/admin.Quote:
Originally Posted by DrByte
Lol ... those came directly from the Edit Orders mod.Quote:
Originally Posted by lat9
Will have to look at those separately.
This should help with that: https://github.com/zencart/zencart/pull/847Quote:
Originally Posted by lat9
Unfortunately security analysts would call it a flaw, not a feature.Quote:
Originally Posted by lat9
Trying to find the balance ...
I know what you're referring to.Quote:
Originally Posted by lat9
I added another dummy language so that the box would show, and it shows up just fine:
Attachment 16073Attachment 16074
I'll admit, I did a "selective" (i.e. copying files) mini-upgrade from a previous download of 155 rather than go through the whole install process. I'll give the full process a go, but an puzzled as to why the difference exists.Quote:
Originally Posted by DrByte
Quote:
Originally Posted by DrByte
Attachment 16075 I can confirm, I have the same issue as Lat9
The coloring comes from the default color values provided by both the CSS3 Buttons and CSS3 Admin Buttons plugins, not the EO plugin itself.Quote:
Originally Posted by DrByte
That change (at least) doesn't kill the overall styling. I can see how adding a <script> tag could be a-bad-thing, but basic styling like a <span>, <em>, <br> or <strong>? Really?Quote:
Originally Posted by DrByte
It's not mangling the <span>. It was mangling the =" part (ie: in style=" ).Quote:
Originally Posted by lat9
Anyway, you have the fix.
Install using demo products; Catalog->Products Expected date display issue. All dates display as 11/30/2036; the products_date_available values in the database are 0000-00-00 00:00:00.
What version of PHP and MySQL, and operating system on that server?Quote:
Originally Posted by lat9
I haven't seen it mangle the dates to be zeros on any Ubuntu or Mac server, using PHP 5.2, 5.3, 5.4, 5.5, 5.6, or 7.0, or MySQL 5.5 or 5.6. And latest cPanel.
Need to know a lot more details about the specific server you encountered that on.
It's an XAMPP installation (PHP 5.4.27, mySQL 5.5.36) running Windows 8.1. I'll retry the installation (from fresh) to see if it replicates. This installation started with the very first 1.5.5 beta and has been incrementally updated from there, so it's a bit suspect.Quote:
Originally Posted by DrByte
I can't replicate the Products Expected issue on a fresh install of the 155 branch contents downloaded a couple of minutes ago.
There is a small bug in /admin/includes/init_includes/init_errors.php
line 165 isand should bePHP Code:if (file_exists($check_path) && is__[/COLOR]writeable($check_path)) {
ciao from ItalyPHP Code:if (file_exists($check_path) && is_writeable($check_path)) {
enzo
There is a mistyping in the preceding message.
Below how it had to be.
Quote:
Originally Posted by enzo-ita
Quote:
Originally Posted by enzo-ita
Also, the line number is off... On github this is currently line 52 not 165 for ZC 1.5.5.
Also there is a ZC function with that name in the filesystem so not necessarily an error.
Okay.. Sorry, I looked at several wrong versions of the file... Anyways, there is a function is__writeable that has been added at least to the admin side in includes/functions/general.php which means that the code should work. Not sure how/when line 165 existed to have that content (personally not going to search for that), but the current version does have the function (two underscores) as well as that usage in that file.Quote:
Originally Posted by mc12345678
Thanks. Good eye to spot that. However, it is intentional.Quote:
Originally Posted by enzo-ita
We might rename it to zen_is_writable in 2.0 or something, but for now the double-underscore is intentional.
Fresh new install on a Wamp server. localhost/morrisgiftshop/zc_install/index.php is this an upgrade or new install?
ERROR:
500
Well, it is not a matter of good eye. I do not remember what caused it and I can not reproduce this but I got an log file saying that a call was made to a non exsisting function is_writable and I found that that function was written is__writable.Quote:
Originally Posted by DrByte
Now you tell me that i__writable is intentional so I think I need to correct that back. Right?
Ciao from Italy
enzo
About the line number, I noticed that a weird problem happens to me. I use notepad++ for editing files. Some files when dwld with livezilla for editing gets added empty lines. If I delete the empty lines then the file becomes unusable. Probably I indicated line 165 becaus of that reason.Quote:
Originally Posted by mc12345678
ciao from Italy
A 500 error is often hard to track down, and typically means a security problem has happened on the server, or PHP has encountered a fatal error.Quote:
Originally Posted by mtechama
If it's a PHP problem, you may find it explained in the /logs/ folder. The logs for zc_install are named zcInstall_xxxxxxxxx.log and if they're reporting a PHP error, they're zcInstall-DEBUG-xxxxxx.log
Found and fixed the CSS for this.Quote:
Originally Posted by lat9
Thanks for the update.Quote:
Originally Posted by lat9