Replace date input fields with Fit.UI's date picker controls.

Make sure we use ValueRestriction when retrieving potentially unsafe values using SMEnvironment::GetXYZ(..)

On PHP 7.2.x users may see the following error:

Deprecated: __autoload() is deprecated, use spl_autoload_register() instead in /Users/jemt/www/SMCMS-JSShop/base/phpmailer/PHPMailerAutoload.php on line 45

See q2a/question2answer#569 for details.

The problem arises because PHP detects that a deprecated __autoload function is present, and throws the warning even though the function is never called.

Please note that for the next version of SitemagicCMS, there are some dependencies that need updating:

• PHPMailer 5.2.27 - Sitemagic uses 5.2.21 which has some serious security vulnerabilities!
• FontAwesome 5.8.1 - Sitemagic uses v4.5.0 (super-old!)
• jQuery 1.12.4 - Sitemagic uses 1.11.0 (super-old!)
• jQuery UI 1.12.1 - Sitemagic uses 1.10.4 (super-old!)
• TinyMCE 3.5.12 - Sitemagic uses 3.5.11 (super-old!)
• +others that I haven't spotted yet :)

All of these bring various security and performance tweaks, that shouldn't be ignored.

Thanks!

Upgrading a website with custom extensions results in lose of these extensions - they are never restored.

CURL related errors are being hidden from the user when upgrading to the developer version of Sitemagic CMS.

Specifying a dynamic page width (e.g. 80%) causes Image Montage to lay out photos incorrectly - basically the layout becomes a mess. This probably occur when the container obtains an "odd" width such as 791.29px as a result of the dynamic width. Make Image montage "floor" the width to e.g. 790px instead.

Using SMShop on XML based installations should either be prevented, result in a warning, or be optimized to prevent performance from degrading over time as the number of orders increase.

Investigate how much data can be handled with decent performance.

Currently mail templates are built using HTML - use Fit.UI's HTML editor instead.
Also add better UI controls for constructing PDF attachments.

In SMDataSource.classes.php we have code such as

if (ini_get("mysql.max_links") !== "-1")
        throw new Exception("The number of MySQL connections allowed cannot be restricted (mysql.max_links)");

The code fails if ini_get(..) returns False. It should always assume the default value when False is returned.

http://php.net/manual/en/mysql.configuration.php

Problem initially reported on Facebook:
https://www.facebook.com/SitemagicCMS/posts/1644836868882246

Add support for sending e-mails using an SMTP server with a self-signed certificate:
https://github.com/PHPMailer/PHPMailer/wiki/Troubleshooting#certificate-verification-failure

After purchasing goods the user is taken to a "Thank you" page - the receipt. But that page is static and currently does not provide any details about what the user bought, where to it will be shipped, the Order ID, or any other important information.

Either make it possible to have this information shown on the page, or allow the user to immediately display the content of the confirmation e-mail sent to them, including any PDF files attached.

Many users are not capable of installing language packages manually using FTP. An import function in Language Editor would be a great help.

Not being able to retrieve a header value by its name is annoying - add this feature to SMEnvironment. See http://php.net/manual/en/function.getallheaders.php - and take note of http://php.net/manual/en/function.getallheaders.php#84262 for improved compatibility!

Make it possible to configure PSPI logging from SMShop (boolean/checkbox). Make sure log is not publicly accessible. If we decide not to support SMShop without URL rewriting (#48) then we can simply make it inaccessible using htaccess. Otherwise simply log to a php file starting with <?php exit; ?>.

Make it possible to view and clear the log from SMCMS!

Searching for strings containing special characters such as æøå/ÆØÅ results in no matches.

Subsites are lost after upgrading using Web Installer.

Make it possible to configure next OrderID and InvoiceId to use (under Advanced).

It's a bit odd that NextOrderId and NextInvoiceId is stored in SMAttributes rather than SMShop's XML configuration file, but it's due to the fact that we need locking capabilities which SMAttributes provide.
Make sure the explanation above is added as a code comment where NextOrderId and NextInvoiceId is used to prevent any confusion.

VERY IMPORTANT:
Only save these values if they have been changed! The owner may load the config, wait 10 hours while 5 orders are received, and then hit Save. That will bring the OrderId back to a value that has already been used.

QuickPay config should not expose the "Cancel URL" option (text field) - that should be provided by JSShop/SMShop as a drop down menu.

However, this will require changes to PaymentServiceProviderInterface as a Cancel URL is not part of the interface.

Is this configuration option required by QuickPay? If not, consider removing it - although it makes sense being able to get back to the website. Does DIBS provide something similar? What about other payment providers ?

Right now, SitemagicCMS SQL uses CHARACTER SET latin1 COLLATE latin1_swedish_ci;

If you check the Character Encodings Usage, you'll see that latin isn't used anymore.
The default now, is UTF-8, so we should convert to this.

Also, the xml encoding="ISO-8859-1" was replaced by UTF-8, so this should be changed too.

Currently SMShop will only work with URL rewriting enabled. Is that acceptable ?

It's inconsistent with how SMCMS is designed - everything else works without URL rewriting.
On the other hand - will anyone really run a serious web shop without user friendly URLs? Unlikely.

If URL rewriting is a requirement, make sure to prevent activations and display an explanatory error.

Changing the link color using the Designer does not seem to work for the page editor - the links remain blue. The same applies to Custom Elements - example:
<div class="SMDesignerElement" data-id="My element" data-preserve="true">Hello world</div>

Links for custom elements in designer.js - search for:
css += ".SMDesignerElement[data-id='" + customs[i].getAttribute("data-id") + "'] a";

Links within TPLContent container (page) - search for:
css += "div.TPLContent a";

Fit.UI recently introduced a very neat templating engine that allows us to separate HTML from JS and work with data in the template in an object oriented way. We already have HTML separated into "passive views", but the presenters would greatly benefit from using Fit.UI's templating - it's much cleaner and easier to use.

Event signatures for JSShop.Events.On****(req, model[], operation) events are a bit odd.
The same applies to Models/Base.On****(req, model, operation) events.

It should probably be something like:
On***(model, eventArgs { Request: req, Operation: operation, ... })

Also rename JSShop.Events.OnSuccess to OnResponse and JSShop.Events.OnError to OnFailure for consistency.

Currently the Web Updator does not backup MySQL database tables nor does it upgrade them. This should be part of the script.

The function SMStringUtilities::Search(..) was introduced in commit 6aff060 - unfortunately the signature is inconsistent with other functions.

Replace
public static function Search($string, $search, $caseSensitive = true)
With
public static function Search($string, $search, $caseInsensitive = false)

It makes better sense to pass a value of True to change the default behaviour of the function.
This change will also affect the SMSearch extension.

1. Searching for e.g. "&" results in value changing to & in search input field.

2. Searching for e.g. "Me & My" results in no matches in page data since & is encoded in page data (&amp;). The same problem applies for less-than (<) and greater-than (>).

3. TinyMCE encodes tilde (~) using a numeric HEX entity (&#126;) which gets decoded by SMStringUtilities::Search(..) and therefore matches a tilde in the search argument, but the character remains encoded in page content data which prevents the matched value from being highlighted.

4. If a page contains a value such as "amp" (e.g.: Our amplifiers and other products) then this will results in amp being highlighted in &amp; entities causing them to become invalid and therefore shown as HTML in the search results. This problem applies to any value that may be found on the page and also used in HTML/HEX entities (e.g. numeric values).

Get rid of mixed syntax for variables/placeholders in e-mail templates ?

E.g. {[OrderLineProductTitle]} for order data, {FirstName} for payment form data.
${[(condition ? "x" : "y")]} for conditional data (which is fine).

We might come to the conclusion that the difference is beneficial since it makes it obvious whether data is related to order data or form data.

Show loading indicator (status with percentage) when using Capture/Reject/Invoice buttons - each requests could potentially take seconds.

Currently we receive the "Invalid state" warning if trying to e.g. capture an order in "Initial" state (it must be "Authorized"). The same may happen when rejecting a payment.

If a network communication error occur, or if the backend returns a warning (try rejecting an order that has already been captured), most often we get a very generic error.

We need to improve this to make JSShop easier to use. As a minimum we should show the error returned by the backend - or better yet, make a localized version of the error message for user-friendliness.

While performing some tests on https://sitemagic.org/ I've found the following:

• https://validator.w3.org/nu/?doc=https%3A%2F%2Fsitemagic.org%2F
• https://gtmetrix.com/reports/sitemagic.org/Mv7eGMQr
• https://developers.google.com/speed/pagespeed/insights/?url=https%3A%2F%2Fsitemagic.org%2F

As you can see, some tweaks are needed.
Thanks!

Consider making all templates fully responsive by leveraging the many new Resolution Breakpoints. It would especially be useful to get rid of of the fixed width on the Page container.

Notice that the Seasons template has an optimization under Advanced in the Designer that reduces the page width from 1100px to 900px when the width of the browser gets below 1400px.

Aleks Syngur has sent us a ukrainian translation package (attached). Add this to an upcoming release.
Ukrainian.zip

A template "inheriting" data from another template should cause SMConfig to read dependencies from the template from which data is copied since demo data may require certain extensions to be enabled.

The best solution would be "merging" Dependencies from the template being activated as well as dependencies from the template providing demo data.

Currently an extension cannot be enabled unless Main.class.php is declared:

<?php class SomeExtension extends SMExtension { } ?>

An extension without the extension declaration will cause the following exception when enabled/disabled:

An unhandled error occured

Call to a member function Enabled() on null

Stack trace
0 /Users/someuser/www/sitemagic/extensions/SMConfig/FrmConfig.class.php(710): SMExtensionManager::SetExtensionEnabled('myextension', true)
1 /Users/someuser/www/sitemagic/extensions/SMConfig/FrmConfig.class.php(310): SMConfigFrmConfig->saveConfiguration()
2 /Users/someuser/www/sitemagic/extensions/SMConfig/FrmConfig.class.php(61): SMConfigFrmConfig->handlePostBack()
3 /Users/someuser/www/sitemagic/extensions/SMConfig/Main.class.php(43): SMConfigFrmConfig->__construct(Object(SMContext))
4 /Users/someuser/www/sitemagic/base/SMController.class.php(394): SMConfig->Render()
5 /Users/someuser/www/sitemagic/base/SMController.class.php(187): SMController->loadExtension('SMConfig')
6 /Users/someuser/www/sitemagic/index.php(27): SMController->Execute()
7 {main}

Please note that you should add the following tools to the repository:

• https://scan.coverity.com/
• http://jshint.com/about/
• https://travis-ci.org/

These will help with code quality testing.

Make it possible to set different State (Initial/Authorized/Rejected) for orders. The real value should not be overridden - save alternative value in different field, but let the alternative value be the one shown in the order list and have mouse over or similar expose the real value. Indicate that the value has been changed with an icon.

The user should be able to type a value, but also select previously entered values from a drop down - or there should be an option to configure selectable states to avoid assigning invalid values.

There is several TODOs and TBDs in the code - search through them, identify tasks, create them in the issue list, prioritize, and fix them.

We have several hardcoded UI strings that needs to be replaced by language strings. Also make sure we don't have any unused language strings.

We need a helper function that easily allows us to obtain Basic Authentication with just one call.

Consider the following.

The base font size is set on . Any adaption to resolution (resolution breakpoint) is set on , and naturally any font-size override is set on specific elements such as TPLHeader, TPLContent, etc.
Unfortunately we do not have the latter containers (TPLHeader, TPLContent, etc) in the Page Editor, so instead we must apply the font-styling to ALL immediate children of which gives us almost the same behaviour.
However, this means that we can no longer have custom elements such as this
<div class="SMDesignerElement" data-id="Customizable element" data-preserve="true">Hello</div>
in the root of our document, and have it work reliably with a custom font-size, since it will first be applied the adaption related to resolution, and then have this overridden by any element specific font-size (see example further down).
The solution to this problem is to wrap the element in another root element:
<div><div class="SMDesignerElement" data-id="Customizable element" data-preserve="true">Hello</div></div>
Obviously this is not ideal but it works when we need to apply different font-sizes for different resolutions, AND adjust the font-size for a given content area as well.

To summarize, this is what happens on the website where everything works as expected (RB = Resolution Breakpoint):
<html>		14px	= 14px
<body> (RB)	120%	= 16.8px
TPLContent	1.25em	= 21px (correct result)

This is what happens if we do NOT apply resolution specific font-size changes to the root elements in <body> in the page editor, but incorrectly applies it to <body> instead (which we currently does) - RB = Resolution Breakpoint:
<html>		14px	= 14px
<body> (RB)	120%	= 16.8px (adaption related to resolution breakpoint is overridden below and hence lost)
<body>		1.25em	= 17.5px (overrides previously value set - no longer results in a value of 21px)

This is what happens when we DO apply resolution specific font-size changes to the root elements in <body> in the page editor (RB = Resolution Breakpoint):
<html>		14px	= 14px
<body>		120%	= 16.8px
<body> > *	1.25em	= 21px (correct result)

BCC E-mail option in Config model and presenter is 100% backend oriented - it has nothing to do with JSShop. Move it to SMTP in SMCMS or allow backend to expose custom settings.

All public functions should make sure valid object types are passed to them - this applies to both backend and frontend.

A large page is only partially printed - content that does not fit on page 1 is simply hidden.

Changing or specifying the width of the page or the footer breaks the "stretch across page" feature for the footer in the Designer - it does not stretch but assumes the width set on the page or the footer.

At some point (JSShop "version 2") allowing for custom data attributes on products would be great - especially if different types of products could have different types of custom data associated. Selecting a "product type" would expose the relevant additional data, and such data would be displayed on the product details card in a table like view - example

CPU: Intel i7 2.5 Ghz
Memory: 16 GB DDR3
Battery life: 10 hours
etc..

It would be amazing if you could finish the http://jsshop.org/ development and integrate it into SitemagicCMS as a default extension.
This would make Sitemagic PERFECT! 😃

Rather than constructing JSON as strings in Configuration.callback.php, consider using associative arrays and json_encode(..) to turn them into JSON objects.

Please note that we need Bot/Spam protection for the Contact/Comment Forms and Google reCAPTCHA would be the best solution for this.

Add support for product variants - e.g. sizes: small, medium, large - or colors: red, green, blue, yellow, orange. During checkout a given product variant should probably be exposed to the expression engine, allowing to construct discount expressions based on selected variant.