On Prestashop 1.4 you can add stores on BO "AdminStores", but you only can upload ONE picture, I need to upload more, anybody have some modification for these?
Thanks!!
PrestaShop has a "Spaghetti and meatballs" code architecture. They have (at least they used to have pre 1.4) a very hard coded Admin area mixing PHP-SQL-HTML-inline CSS-inline JavaScript, hrm "the works".
You may be able to write a sweet front-end code to associate a Scene to the main home category of that Store you would only need to alter one of the root files.
Making a full-working back-end solution without a module implies some serious hacking and non-maintainable code also you can't allow updates.
You best bet is finding a module but that needs to implement everything including new DB tables and upload interface etc. and then make sure it associates images to Stores.
When in lack of either, solution no.2 becomes imminently more probable if you have the necessary skills.
Related
We have been using Yii for building web applications. Once in a while, themes comes to our discussion table.
But, if we have a web application and we wish to change the look and feel only, we may, as well, change the public_html folder, since the structure will be similar.
The only point we see on having themes is for those cases where we may want to dynamically (user choice by clicking on a "change layout button") change the look and feel of an application.
Does anyone uses themes for any other proposes, or configurations?
We use themes to great effect. We operate 6 sites using as single instance of a Yii application. The theme is then selected based on the domain name.
Yes we could have just used 6 different application folders and served them separately. This comes with several advantages though, which you've probably already dismissed if they're not relevant to you, but here they are:
Shared code, updates and maintenance are far easier
Adding a new theme is much cleaner IMO (just a new theme folder rather than a whole application directory)
Global assets, which are then overridden easily in the theme, rather than wiping over them completely, you'r expanding them.
Shared Cache, the whole application caches to a single directory, view cache, data cache etc.
Shared Assets directory, assets are only published once ( although this could in theory be set up in a copied environment)
I much prefer this set up, it looks far cleaner just to override rather than overwrite. Plus really, I can't think of a reason why copying the whole directory would be better than this method, yes there are issues in theming that have to be worked out, but copying the whole source doesn't solve them.
Let say my iOS app already have translation localizatible.strings for Japanese. Say "Continue" = "続ける";
However, I've added new NSLocalization additions to my code but I want to use genstrings to get all new NSLocalizations without having to merge them manually.
Is there any way to do that?
There are tools that manage localization and that automatically make updates to translations based on changes to the base language (and helping the translator make the necessary changes only to whatever has been changed).
For example www.gengo.com has a free online tool called Strings (which I haven't tried yet). There are also desktop apps that look very good, such as Localization Manager as part of Localization Suite http://www.loc-suite.org/ (which I haven't tried properly yet either).
Localization agencies may have their own tools, too.
These tools are a must if you do a lot of updates and have several languages but for smaller projects, they can take a bit too much getting used to. For an occasional task or a small project with few languages, manually merging the changes of your base language localizable.strings files to your translated localizable.strings files might be quicker though.
We're planning to launch a serie of applications in AppStore. They will be for some kind of different journals, showing different contents downloaded from a server via XML. So these applications will be made from exactly the same code (It's an universal application, so It'll work both in iPhone/iPad).
My initial idea was, in order to upload the application, compile just changing the images, logos and configurations (plist) that makes the application react as a particular journal. The compressed file would be uploaded to the AppStore.
However, this has resulted a horrible method, which promotes failures and mistakes. If I forget to change some image, as you can't see them in the compiled file (as it is included) they will end up in the store (and I will need four or five days in order to get the application changed).
I'm trying to look up for a better approach, wich keep the projects as independent as possible. I would like to be able to share the entire codebase: views, classes and nibs and create different projects for every journal.
Which is the best method to achieve that?. What structure would let me group both logic (controllers, classes) and UI and use it in the different projects?.
I hope I've explained.
As always, thank you very much.
You should keep most of your common code as a library project. Each final project should link with this project and provide images/assets along with code to mention these assets to common code. In my day job, I write a common library too, which gets used by 2 products/apps at my employer.
An Xcode project can have multiple Targets, all the Targets sharing code, but each Target getting its own resources (icons, images, text, plists, etc.) from a different subdirectory/folder within the same project directory/folder. Then you can check the whole thing, or just the shared source, into your source control repository.
You should also be testing each of your apps, built exactly the same way as any submission except for the codesigning, on a device before uploading to the store.
You can have a single Xcode project that creates multiple applications. You'll need to create a separate Info.plist with a different bundle identifier for each app.
If you are using a git repository you can just branch for each different app you want and that would keep track of all the differences and if you need to switch which you are working on you just have to checkout that branch. This would allow for the exact same structure just minor differences between the actual code for each.
I'm new to MODx, but am quite impressed with its power and flexibility. There's only one caveat, and I'm hoping it's just because I don't know any better.
I'm a frontend dev, and I'm used to building websites of all sizes. But I usually work with files and version control. How would I keep this paradigm with MODx?
From my poking around so far, the only way I found to use an IDE, is to keep static files with my code, to later on copy/paste into MODx Manager. Far from ideal.
I'm aware that a lot of people use an "include" snippet, to include snippets, chunks, etc. Does this work for MODx specific tags? For example, if I include a file as a snippet, and I have a template variable defined in there (or a resource link), would that be properly rendered?
Also, is there a performance hit using a snippet by including a file, vs having the snippet code entered into MODx Manager?
Bottom line, how do you develop sites on MODx? Where do you enter your code? Is there a feature like the "Import HTML" but for snippets and chunks? Is there a way to create new Templates, Documents, Chunks, TVs, etc. without going through the Manager?
Thanks in advance!
there is a whole documentation site for developing in modx, http://rtfm.modx.com/display/revolution20/Home - though it mostly concerns extending it - not customization & modification. The short answer is no, there is no version control for your snippets & such, yes, you will have to maintain them manually. [I wish that was not the case]
Most of your php code will go into either a snippet or a plugin, and yes you can include static files in either of those resource types, no, I on't know if there is a performance gain/loss, but I would imagine "no" if your include is cache-able.
for the includes you can do something like this:
include_once $modx->config['base_path'].'_path_to_my.php_';
-sean
There is VersionX for revolution that will allow you version control of chunks, snippets, resources and so on.
There is package called Auditor that will allow you to implement version control in Modx
EDIT
Sorry just noticed your question is tagged Revolution, Auditor is for Evo. I don't think there's a solution available yet although I believe it is on the Roadmap
The organization I currently work for an organization that is moving into the whole CMMI world of documenting everything. I was assigned (along with one other individual) the title of Configuration Manager. Congratulations to me right.
Part of the duties is to perform on a regular basis (they are still defining regular basis, it will either by quarterly or monthly) a physical configuration audit. This is basically a check of source code versions deployed in production to what we believe to be the source code versions in production.
Our project is a relatively small web application with written in Java. The file types we work with are java, jsp, xml, property files, and sql packages.
The problem I have (and have expressed but seem to be going ignored) is how am I supposed to physical log on to the production server and verify file versions and even if I could it would take a ridiculous amount of time?
The file versions are not even currently in the file(i.e. in a comment or something). It was suggested that we place visible version numbers on each screen that is visible to the users also. I thought this ridiculous also, since the screens themselves represent only a small fraction of the code we maintain.
The tools we currently use are Netbeans for our IDE and Serena Dimensions as our versioning tool.
I am specifically looking for ideas on how to perform this audit in a hopefully more automated way, that will be both accurate and not time consuming.
My idea is currently to add a comment to the top of each file that contains the version number of that file, a script that runs when a production build is created to create an XML file or something similar containing the file name and version file of each file in the build. Then when I need to do an audit I go to the production server grab the the xml file with the info, and compare it programmatically to what we believe to be in production, and output a report.
Any better ideas. I know this has to have been done already, and seems crazy to me that I have not found any other resources.
You could compute a SHA1 hash of the source files on the production server, and compare that hash value to the versions stored in source control. If you can find the same hash in source control, then you know what version is in production. If you can't find the same hash in source control, then there are untracked modifications in production and your new job title is justified. :)
The typical trap organizations fall into with the CMMI is trying to overdo everything. If I could suggest anything, it'd be start small & only do what you need. So consider any problems that you may have had in the CM area peviously.
The CMMI describes WHAT an organisation should do, but leaves the HOW up to you. The CMMI specification, chapter 2 is well worth a read - it describes the required, expected, and informative components of the specification - basically the goals are required, the practices are expected, and everything else is informative. This means there is only a small part of the specification which a CMMI appraiser can directly demand - the goals. At the practice level, it is permissable to have either the practices as described, or acceptable alternatives to them.
In the case of configuration audits, goal SG3 is "Integrity of baselines is established and maintained". SP3.2 says "Perform configuration audits to maintain integrity of the configuration baselines." There is nothing stated here about how often these are done, or how long they may take.
In my previous organisation, FCA/PCA was usually only done as part of the product release process, and we used ClearCase as the versioning tool, with labels applied across the codebase to define baselines. We didn't have version numbers in all the source files, nor did we have version numbers on all the products screens - the CM activity was doing the right thing & was backed up by audits, and this was never an issue in any CMMI appraisal.
We could use the deltas between labels to look at what files had changed, perform diffs to see the actual code changes. An important part of the process is being able to link those changes back to either a requirement/bug report/whatever the reason was which initiated the change.
Our auditing did use scripts to automate the process, but these were in-house developed scripts are specific to ClearCase - basically they would list all the files, their versions in the CM system, and the baseline/config item to which they belonged.
can't you use your source control for this? if you deploy a version and tag your sourcecontrol with that deployment, you can then verify against the source control system