From ViArt 3.5 the idea of putting templates in a user defined templates folder which is scanned first for changes to the supplied templates is a really useful, well thought out idea.
 
It makes modifying appearance very much easier and of course the "changes" folder doesn't get overwritten on upgrade making subsequent changes easier as new versions of templates can be checked against any modification.
 
Its such a good idea I would like this concept applied to the whole system.
 
At present the prefix to database entries can be changed by altering the variable "$table_prefix" in "/includes/va_definition.php" which allows different incarnations of the software to share the same database.
 
I'm suggesting another entry in the definition file - $user_prefix which is initially set to "".
When loading a php file the software first looks for an entry with the $user_prefix and if it doesn't find it "falls back" to the non-prefixed version.
So without the user prefix the cart behaves normally, with it programmers can create modified php files _without_ changing the originals.
 
Because the control is in "va_definition.php" its not apparent to the normal user but the programmer can tailor the php files to their advantage without them being overwritten on upgrade.

I second this request!

I think the custom modification accept is a key if viart do not want to loose Customer's creativity.
 
In other systems I found /custom folders, and phps, like custom-header.php foe example.
 
Also we could send our working customisations - In a new Forum Main topic -, that needs just some tweaking to implement to the new releases.
 
I think I need just customisations what uses the available databese, and simple feature to add custom fileds to db tables.
 
If Viart open to this cilcre (Customer made some script - Others test it - Viart implemets it) will be more time for the support...
 
What do you think?

I agree customisation is a key but in all things an ordered approach is required if we do not cause fragmentation. The proposal above provides minimum disruption to the existing layout (in fact its "hidden") and thus doesn't create /custom_folders - all customisation is prefixed "custom_... " or whatever the user decides. It also uses less processing overhead which is important if the software is to be responsive.
 
Dan has already set up http://communityexpansion.com/ and this is probably where the developers might discuss detail.
 
I expect then that ideas generated and tested there will be fed back to ViArt but to allow this, the structure must be in place to allow it in the first place.

Ive been told by support that they will be addressing this issue in a future release.
 
...However they didn't say when - or how.

Viart guys, are you reading this?!?! Please add this, it would be a life saver!!!

I asked support if there was progress on this and said
"The reason I think its important to release this _before_ 3.6 is so users can pre-modify existing sites before the next major upgrade."
To which they replied..
"We do not plan to add it in this release."
 

Just to keep everyone up to date Natalia has said "Most likely the changes related to easy PHP modification will be added to the next official release.".
 
So its more of a wait Im afraid. They still havn't given a suggestion of how they intend to implement it - so Ill ask.

Hi All, Just a "heads up".
 
With the release of 4.0.6 I'm passing on a suggestion made by support and hopefully they will include this in the release. Its not there as of now and support say they are looking at any impact on speed of use.
You can add this to previous versions.
 
The modification allows the user to change the php code running in blocks. You can already change the templates in a similar way.
 
The modification is twofold.
First create a folder in the root of the software called "blocks_custom"
 
Then in "includes/page_layout.php" change
include("./blocks/".$php_script);
 
to
 
if (file_exists("./blocks_custom/".$php_script)) {
include("./blocks_custom/".$php_script);
} else {
include("./blocks/".$php_script);
}
 
This then looks first in your folder and if there's no modification then the software looks in the original.
 
Because the folder "blocks_custom" isn't in the release it doesn't get overwritten on upgrade.
 
HTH

Support have now incorporated this modification into the latest build of 4.0.6.
 
If you modify a blocks php put it in a folder called "blocks_custom".
 
If you don't modify a blocks php then the original code in "blocks" is used.
 
If you upgrade your changes shouldn't be overwritten but you do need to check (obviously) for changes to the original php.
 
HTH and many thanks to Support.

Thanks Ned! This is nice that it's incorporated into the new version. I already made this mod a little while back and title'd the folder differently, but with the name change, it works smoothly, and updates will not require me to redirect to the folder. Thanks for getting this taken care of!

Excellent work Viart, this will definitely help the developers to make changes.

this needs to go deeper...
 
we should be able to for instance create a js_custom and viart should pick that up, etc etc
 
much better.
 
Fairly easy to add ourselves but it should be there instead of a half-done job.