Recently we had a magento audit and one of their suggestion as follows:
Location:
app/design/frontend/enterprise/mytheme/template/catalog/product/list.phtml:59,
Type: Maintainability
Name: Hardcoded Value
Priority: Low
Description: Hardcoding values like product type code, store id, file name, credentials, etc. may cause serious issues during future upgrades or porting.
Recommendation: Such values can be stored in class constants or in the system configuration for the best flexibility.
Example:
Mage::getConfig()->getOptions()->getSomeSku()
If we add custom code in custom theme, will that affect during upgrade?
Custom vs. hard-coded
The issue here is not the fact that the code is custom. It's the fact that the code is not upgrade-safe.
Why hard-coding is bad
Hard-coded values aren't easily accessible for future changes. Updates may perform unexpected actions and you may end up with a broken page because of it.
The values themselves can become obsolete if an upgrade procedure re-creates an object (deletes and saves) and the object ID changes because of it.
Upgrade-path
The topics approached by an audit team are intended to help you to achieve an automated upgrade-path. Meaning that if you would respect all of those suggestions they made running your upgrade should be clean and error-less. Otherwise your debugging day has just arrived.
Related
I am currently trying to migrate Forms' Applications developped ten years ago to Oracle Apex. For some context, the database in which Forms applications are currently running is the Oracle EE 6i, and will be soon upgraded to the 12.2g, hence the need for migration. The data stored within the tables is to big to migrate (like 4To) so we need an alternative to Forms, but we cannot change the DB, and cannot keep Forms (which is let's be honest, outdated a little). I am currently on Oracle XE for my tests and on Apex 20.2.0.00.20 to start my migration (before upgrading).
The thing is, I have some issues with how Apex and Forms are working differently.
I am really blocking on the following issue since my migration:
In Forms, it was really easy to change the color of a button for exemple by calling a Forms method in a certain way depending on a condition (for exemple a SELECT return). Here, in Apex, I am trying to do the same.
I know that there are ten other ways of doing the same, with JS for exemple which I already succeedly do, but when I tried to create my second appplication I realised that compared to Forms, Apex cannot reference/generalise parts of the code(or applications) for different applications (and certainly not for different workspaces). So Javascript is a good solution but not as efficient as PL/SQL which is easier to generalise and will (in my opinion) use less exchange between the db and the client, since stored on the db.
That is why I decided to rely on PL/SQL Stored Procedure which will be specified in the database and called directly in each application where I need the process/computations.But I cannot find the same as in Forms, with my graphical methods helping me do what I need.
I am open to alternative of PL/SQL package/procedure/function if it can keep the same propreties (generalisation and minimum echange between client and db). These are important point since I have around 200 applications to migrate, starting with what we can call 'brick' which will compose the other simpler applications.
Btw: CSS is an option I studied, like HTML with PL/SQL dynamic content but I read that it was either not simple enough to integrate, or that it could be deprecated, so if it is the solution you are using, I could use a really detailled explaination or an exemple.
To give you an instance:
I click on a button triggering a PL/SQL stored procedure
Procedure checks some conditions in the db (like if a process is currently running)
PL/SQL update a table, change a variable in procedure and returns 'green'
The button becomes green, a message is displayed ('You have permission to do this!')
PS: if there are Apex Method modifying the graphical aspect, could I have a documentation ?
Thank you a lot for helping me resolve this issue, I have been stuck for days...
I tried Javascript bu the generalisation was too much a problem. I tried the HTML injecting but didn't work, I tried updating CSS but was not what I expected. I tried different PL/SQL method but couldn't find a way to connect PL/SQL with Apex/CSS/HTML...
It takes a bit of getting used to how APEX works, but everything can be done and once you get up to speed, you'll find there pretty simple ways to get things done. To achieve what you describe, this is what you'd do.
Create a dynamic action on click of button
Add the following actions to the dynamic actions
an action of type "execute pl/sql". This is your "Procedure checks ...". In this pl/sql code you can set page item values (make sure to reference those in "items to return" so the new values is set in the session. There is no reason to have 2 different pl/sql procedures, you can just put them in 1 block. This procedure would return the "green" - but more about this later.
an action to add a class to the button under certain conditions.
Note that the "green" is not something you should decide. In apex, there are a lot of layout modifier classes pre-defined. In your case, it makes sense to use the "success" modifier (which happens to be green).
To check how you want the button to look, there is a tool called the "button builder", you can use that to see what classes you should add/remove to change the look of the button.
Note that 20.2 is not a recent version. It was released in 2020. Since then 4 more releases have been made available: 21.1,21.2,22.1 and 22.2. It is advised to be on the latest version.
Here is a basic example. I have a page with a select list (P117_SELECTLIST), a hidden item to hold the button status (P117_BUTTON_STATE) and a button (MYBUTTON). The select list has 2 static values:
The dynamic action for serverside code is :
Note the items to submit and return values. P117_SELECTLIST is submitted so the pl/sql process picks that up from the client and P117_BUTTON_STATE is returned to the client so it is available for any future use.
Then I have 4 classes to set the button style. One to add success class, one to remove success class, one to add warning class, one to remove warning class. Below is the first one. The only think different in those 4 actions in the class name and the client condition. It can probably done with javascript directly as well with only 1 action.
I'd strongly suggest to update the db version to a version that supports the latest version of apex. It will save you a lot of development worries. Most people of forums only have the latest version available.
I beat myself up for two days as I built a Ruby on Rails application that manages users in LDAP. While fine-tuning the inclusion and formatting of various attributes, I would frequently have ldap.add() fail with little feedback other than possibly an exception raised. I usually knew it was a data validation error, such as a missing required attribute or poorly formatted attribute values -- but I could not find anything on the server (Apache DS) or client end that would indicate which field failed, or why it was failing.
So...how do you see the reason why an LDAP add (or replace, delete, open...) failed?
Then I stumbled across ldap.get_operation_result, I had a real facepalm moment. I've intentionally recreated several of the issues I painfully solved through careful inspection with get_operation_result in my arsenal, and each time it described exactly what the problem was.
This function is useful in the case of rescuing an exception, or if add(), modify(), delete(), etc. simply returns false.
ldap.add(dn: dn, attributes: attributes)
Rails.logger.info("ldap.add: #{ldap.get_operation_result}")
The snippet above saved my sanity, not to mention hours of tedious hunt-and-peck testing.
For example, here is just one part of an error message it revealed that I did not provide the required sn attribute:
ERR_279 Required attributes [sn(2.5.4.4)] not found within entry uid=david,o=users,dc=example,dc=com"
It will also show messages related to bad server connection credentials, etc.
HTH
I have a custom entity with the following StateCode/StatusCode definition:
State ACTIVE
Active (value: 1)
Completed (value: 821290000)
State INACTIVE
Inactive (value: 2)
Inside a form, I put Status Reason option set in the header for users to change as needed (in short: once they are done with the record, they change status reason from Active to Completed).
In the production environment (SP1 UR3 - version 6.1.3) the status reason Completed is missing and we only see Active.
In one of the development environment ('vanilla' SP1 - version 6.1.0) the exact same form shows both Active and Completed status reasons as expected.
Status Reason field shows the options are both there in both environments.
The two environments are exactly the same customizations-wise, there isn't any code which removes options from the option set (I wrote all the code for that entity, and I also triple-checked to make sure I wasn't overlooking anything).
Is this a bug in UR3 ?
UPDATE: I'm told the issue was permissions-related, going to post an answer with the details once I recollect them.
I haven't heard of any bug of this sort.
Did you check if the status reason field on this custom entity has all 3 of those options in the field schema, and they are just not showing on the form? This would help determine if there is some kind of form scripting issue/display issue versus a schema issue (like what pkr asked)
If you were to export the default solution and compare the customizations.xml files, are there differences? If there are truly no differences between the two customizations files (meaning the environments are completely identical in terms of CRM customizations), then there has to be some kind of scripting that is causing the other option to not display in one environment based on some data but is showing in the other because the data is different.
This questions is related to Kohana ORM AND Caching module. I use version 3.2 if it matters. I tried to research trust me, but I really couldn't find some good answer... so here it is:
What are the correct ways to use ORM::cached() and ORM::serialize() and ORM::$reload_on_wakeup?
I've seen many 2-line code examples but never anything really solid on the userguide/api...
What is the difference between enabling Cache module and 'caching' => true in Kohana::init?
Anyone has any recommended approach for the following specific situations? I have a catalogue page that upon profiling, I realized two very expensive actions:
I queried database each time for a currency model for each item, when the currency information can really be reused.
I queried database each time for each item's inventory item, this is an expensive query, which I wish I can cache until inventory level changes.
References that I found but couldn't answer fully my questions:
http://forum.kohanaframework.org/discussion/1782/tip-for-caching-orm-objects/p1
http://forum.kohanaframework.org/discussion/10600/does-kohana-orm-and-cache-work-together/p1
Just found your question, maybe too late, but maybe is useful to others:
cached, will force the Query builder to cache the DB query. It uses the KOhana:cache method (file cache) I am trying to find a workaround for this.
enables caching for the file search as says in the Kohana/Core.php file: Whether to use internal caching for [Kohana::find_file], does not apply to [Kohana::cache]. Set by [Kohana::init]
Enable caching true to speed up the file search, and enable the cache module, I am working on a way to cache the queries of DB using the instance used by the module. That would be better than using the file cache. Maybe I am missing something but stuck there right now.
How could we alert a magento site admin about each abandoned cart immediately after it is abandoned?
Is it a default feature in Magento EE?
No it is not a default feature in Magento EE.
You ask how a site admin could be alerted of an event that is somewhat of a grey area.
Assuming that an abandon cart is defined by the following criteria (which in fact is not the definition but may be applicable to you)
A registered user (ignore guest users for sake of sanity here) has products in cart.
This user does not complete the checkout and leaves the store-front
A period of time goes by (eg 1 day) with no adjustments on the cart items
Assuming this situation is your abandoned cart scenario i could suggest the following :
1.) I would use the Magento Quote Object (this is the object that is converted to an order after a successful checkout.)
looking at the quote object there already seems like there are enough fields to be able to monitor when the quote was created, when it was updated, when it was converted and whether it was converted or not. If the object does not contain the data fields you need there is no reason why you could not extend it. See a sample snapshot :
My (naive) suggestion would be to set up a scheduled job, to run at the same frequency at which you define your "abandoned cart" scenairio (or any frequency for that matter).
The job could do something like the following :
1.) Instantiate a collection of quotes.
2.) Filter out quote's that have been converted
3.) Filter out quote's that have been created recently (less than the critria above)
4.) Filter out quote's that have been modified within the same time-frame criteria
at this point you should have a list of all quote's that have been created, perhaps been updated but not converted for the last 24hours (depending on your criteria of course).
If you get to this point, well then the rest is straight forward.
Extract the information you need from the quotes (id's names, numbers, emails etc), compile your report and email to the administrator.
it the best idea i can think of for now! i have not done this in practice...
Ofcourse you can set-up funnels and goals with Google Analytic to give you extensive information on your customers, including abandoned carts, but that doesn't answer your question.