Encoded files

[AndrewMKP]

Ok,

 

This one should end the thread.

 

You tell us what you want to do so badly with the WHMCS system and we will tell you straight up if you need to edit the core files or a work around.

 

If you guys are so intent on having it unencoded then TELL US EXACTLY what you want to do with it.

 

Prove to us, because so far you have just said its an inconvenience, but tell us, WHAT you want to do to the system.

 

Justify your points. When you finally come to realise you can't, then we can close the thread :roll:

[openmind]

Personally I'm actually glad it's encoded for the simple reasons:

 

It does everything we need it do

The things it doesn't do that we can't change are being developed

The things that are not being developed yet get suggested and often implemented

The things we want to adapt we can through the templates

The whole thing takes minutes to upgrade as we know the only folder we have to check is the templates.

 

There is also the issue of code protection. We sell a commercial eCommerce product and the admin area is encoded to protect the years of time and money we have spent developing it. Granted we have a section coming up where users can add to the admin area but on the whole it will remain encoded to protect our investment.

[Ben-iNetFx]

I can't speak for the others, but in my case:

 

1) Edit the Worldpay Futurepay setup so instead of having to click a button which says "Pay Invoice" if details are already on system, take this automatically.

 

2) Amend the Futurepay cron so that it can take an invoice number as a variable, meaning we don't need to run it for every single outstanding invoice each time.

[DataHosts]

I can't speak for the others, but in my case:

 

1) Edit the Worldpay Futurepay setup so instead of having to click a button which says "Pay Invoice" if details are already on system, take this automatically.

 

2) Amend the Futurepay cron so that it can take an invoice number as a variable, meaning we don't need to run it for every single outstanding invoice each time.

 

Why not request as a feature? I use neither, so, I am not familiar with them. However, I am sure Matt will do what he can if possible to assist in this. Instead of complaining about the encoded files (which we all know will not change)...why not spend that time making suggestions to the application to help others enjoy it.

[Karateka]

Ben:

 

we have had a similiar problem with another payment button. We ended up adding a javascript framework to the template (mootools in our case) and then used the framework to modify the HTML output upon pageload (hide the form submission button, auto submit form). You can also use it to trigger events such as a form submission on page load. Of course, all of this can also be done with regular javascript.

[Ben-iNetFx]

Why not request as a feature? I use neither, so, I am not familiar with them. However, I am sure Matt will do what he can if possible to assist in this. Instead of complaining about the encoded files (which we all know will not change)...why not spend that time making suggestions to the application to help others enjoy it.

I did feature request it - but was told that as someone else had already paid for it to be custom coded, it would not be added to the core code until a certain time has passed, however if I paid whatever the custom coding fee is, I could have it too.

 

That made little sense - as it was already written and it's not like they are going to pay the other guy back... thus that road is at a dead end unless the unencoded files can be accessed.

[osCommerce]

Ok,

 

This one should end the thread.

 

You tell us what you want to do so badly with the WHMCS system and we will tell you straight up if you need to edit the core files or a work around.

 

If you guys are so intent on having it unencoded then TELL US EXACTLY what you want to do with it.

 

Prove to us, because so far you have just said its an inconvenience, but tell us, WHAT you want to do to the system.

 

Justify your points. When you finally come to realise you can't, then we can close the thread :roll:

 

Modify the breadcrumbs in my case to add "client area" to the breadcrumb in certain cases if the customer has logged in. In NORMAL circumstances it would be a 2 minute coding job. Because the files are encoded it means rewriting the breadcrumbs to each template page individually. That works in 95% of the pages except for the strange ones where they seem to have ENCODED and forgotten to add a few of the needed smarty variables where now you have to start writing SQL statements to get the info that should have been there in the first place. 2 minutes has turned into 4 days.

 

But at least now I can use the language file text for the encoded breadcrumbs and add the page header to each template file use that create unique page descriptions for all the pages, which would also be a lot easier if it wasn't ENCODED.

 

Unique breadcrumbs is going to change the world but it will make my site much easier for navigation. Unique page titles, descriptions and keywords for each page should have been done in V0.01.

 

 

As for the arguement that people will break it if it was not encoded I people break the template files all the time ... so what if people break a breadcrumb or forget a dot on a line when adding a smarty variable they need. Who cares, it would make the program a lot more flexible. The only things that need to be encoded are files that do NOT touch the template. Smarty variables touch the template and so do breadcrumbs, page tiles, descriptions, keywords. So everything needed to make you site easily look unique is NOT available to use. Half the functions needed to modify the template are encoded and you either have to rip the program apart and rework it ... or live within the constricted narrow view of what the owners feel is needed to run a site.

 

A perfect example of what a pain it is to have the files encoded is on the template file viewannouncement.tpl. Maybe you can answer this, what is the smarty variable for the announcement id number? As far as I can make out the only ones for that page are $date, $announcement and $title. I am not sure if there are more hidden but those are the main ones. Because the file is ENCODED I will never know but it would be a lot easier to finish my breadcrumb if I could just open the file, add the variable I need and carry on with my work for the day instead of spending it "guessing" what the non existent smarty variable for the announcement id is.

 

:roll:

 

I would rather spend my day creating my site rather than playing the game "guess the smarty variable".

[VicToMeyeZR]

^ +1 bro. you hit that nail RIGHT on the head!

[Matt]

In NORMAL circumstances it would be a 2 minute coding job.

And it still should be. In header.tpl you can use the smarty string replace function to change the existing breadcrumb values and if statements to add or remove parts only in certain circumstances like when a customer is logged in as you mention or on a specific page.

 

But at least now I can use the language file text for the encoded breadcrumbs

The default breadcrumbs use the language file text anyway

 

As for the arguement that people will break it if it was not encoded I people break the template files all the time ... so what if people break a breadcrumb or forget a dot on a line when adding a smarty variable they need. Who cares

Most likely you, and every other user, would care very much when support ticket response times start taking 24-48 hours because of the additional time we have to spend looking at a users install, troubleshooting an issue before we find it's a line they've added in one the files. Not only that, but we already get people moaning about having to update a few simple template files when new upgrades are released. Imagine if PHP code was introduced to that with 100 files + changing for a new release...

 

A perfect example of what a pain it is to have the files encoded is on the template file viewannouncement.tpl. Maybe you can answer this, what is the smarty variable for the announcement id number?

The id variable is in the url is it not? In which case a programmer would know it's a $_GET variable. So you have a couple of options: {php} echo $_GET["id"]; {/php} {$smarty.get.id}

 

As far as I can make out the only ones for that page are $date, $announcement and $title. I am not sure if there are more hidden but those are the main ones.

 

All the variables on a page can be seen by entering {debug} in the template file and then visiting the page will produce a popup listing them.

 

Suffice to say the encoding does not stop any customisation. What it will stop for the majority is breaking things, and while it may be an inconvenience to programmers wanting to tweak a module, it's also protecting against others simply copying the modules we've put work into creating. And as was already mentioned, custom development services are offered for anything you can't do by templates, custom modules or hooks.

 

Matt

[openmind]

This is rapidly turning into a pointless thread. Matt has given reasonable, precise and logical answers why the php files are encoded, it's not going to change so that's that...

[bear]

Agreed, it's all been said.

</thread>