I am a junior (barely) dev and recently inherited a Prestashop project (version 1.7.8.2).
In both admin panel and main page all the products have N/A instead of actual name.
Even if I rename them they remain N/A.
ALTHOUGH In Database all the names are displayed correctly.
The site is in French only so in ps_lang table there is only one lang mentioned (Thus it's not possible to add translation to it).
I tried exporting products in CVS then deleted them from admin panel and then importing them again, didn't work.
Did anyone come across this issue? What are possible reasons of this bug?
IDs in tables ps_product and ps_product lang don't match.
Probable solution - try rewrite IDs in ps_product table manually, might take time, might not work, but at least I can see clearly the problem here.
Related
I have a script that deletes specific entries from [prefix]_category_product ( => removes products from a category) using SQL.
Though the changes are successfully made in the database and in the Prestashop admin interface, they don't show on the front-end. Some products which have been removed from a category still appear in it.
I don't think it's a caching issue because emptying the Prestashop cache and the browser cache doesn't work, and they don't disappear after a few days/weeks. If I add and remove the product from the category manually using the admin interface it works. What am I doing wrong?
You are forgetting the ps_product and ps_product_shop tables,
where the id_category_default value is stored.
Is there a way to update the Liferay's site page's friendly name through a SQL script?
We generally do this in the control panel through admin user.
While #steven35's answer might do the job, you're hitting a pet peeve of mine. On a different level, you're doing it right if you're doing it on the Control Panel, or through the API and you should not think about a way to ever write to Liferay's database. It might work for the moment, but it might also fail in unforeseen ways - sometimes long after your update.
There have been enough samples for this to happen. If you're changing data while Liferay is running, the cache will not be updated. In case these values are also indexed in the search index, they won't be updated there and random later uses might not find the correct page without you reindexing everything. The same value might be stored somewhere else - or translated. Numerous conditions can fail - and there's always one condition more than you expect and cater for. That one condition might break your neck.
Granted, the friendly name of a page might not fall into the most complex of these cases, but just don't get into the habit of writing to Liferay's database. Or, if you do, don't complain about future upgrades failing or requiring extra work, because the database contains values that the API didn't expect. The problem is that during the next upgrade (if you do it in - say - one year) you'll long have forgotten that you manually changed data in the database and blame Liferay for problems during your upgrade.
Changing data is exactly what the UI and the API are for.
Friendly urls are stored in LayoutFriendlyURL.friendlyURL in your Liferay database so the following query should work
UPDATE "yourdatabase"."LayoutFriendlyURL" SET "friendlyURL"="/newurl" WHERE "layoutFriendlyURLId"=12345;
You will also need to update the Layout table accordingly to match the new friendly url.
I am developing a django project which lives on Heroku. As the project evolves, a problem occurs when new fields are added to a data model: during makemigration, south will ask something like the following:
...
? 1. Quit now, and add a default to the field in models.py
? 2. Specify a one-off value to use for existing columns now
...
It isn't easy get around this (I tried to choose the second answer but south wouldn't accept whatever I entered).
Questions:
1) Some suggest that null=True should be added to the new field to avoid such a problem. However, the field should not be null. I end up making a workaround: makemigration with null=True, delete null=True, perform makemigration again, and then push to Heroku.
Is this the right way of doing it?
2) Using south migration causes another problem. Because we are a development team, every member may perform migration in his/her environment. When it comes to pushing to GitHub, the 00*_* files in each app's migration folder may conflict each other. How to solve it? Currently, we just ignore the 00*_* files since our project is not in production yet. What if it is in production later?
3) I only ran makemigrations and migrate and never used schemamigration. The system runs fine though. Do I have to run schemamigration?
1)
When you get an error message like that, basically it's asking for a one-off default. What exactly you should put in there when selecting option 2 depends entirely on your situation, but it must be a valid Python expression. For example:
If I have an IntegerField I want to add, I could enter 0
For a CharField, I could use "my string" (Note the quotes must be there)
For a ForeignKey, I would specify the primary key of the object I want to use.
2)
This is the hardest part about South. Conflicting migrations have to be merged carefully, and manually. The Django 1.7 migrations that replace South are much better at doing this automatically, so if at all possible, upgrade to 1.7+.
3)
I believe makemigrations is an alias for schemamigration. Get used to makemigrations because it's what the command is called in Django 1.7+.
Is it possible to promote a file without specifying an issue number?
Related to that question, I see some files which have histories for which the column "Issues" is blank. How does that happen?
Promoting against and issue is an option, rather than a requirement. An AccuRev depot does not have an AccuWork schema until an administrator creates one. Even then, this does not automatically require promoting to an issue. Within the Accuwork schema, this feature can be enabled using the Change Packages tab.
To your second point "... some files which have histories for which the column "Issues" is blank. How does that happen?"
If you've changed over from non-Issue based development to Issue based development and have not associated the files, those with active or (member) status, with Issues, that column will be blank.
More likely some one promoted foo.c to Issue 15. Then opened up Issue 15 and removed foo.c from the Issue. In this case the column will be blank too.
The solution is to find these files, look for the "Unaffiliated Changes", select them, and choose "Send To Issue" then provide the correct Issue number.
I need to show a grid of saved projects (compare "orders") in a datagrid, where the projects are saved in an Access 2000 database with a similar schema as follows:
ID Name Country_ID Plant_Type
1 'Test' 1 1
2 'Second' 2 2
Let's call the file "Projects.mdb". This is then showed in the datagrid as:
ID Name Country Plant Type
1 'Test' 'Germany' 'Free Range'
2 'Second' 'France' 'Inclined Roof'
where the countries and "Plant Types" are fetched from a different table in a different .mdb file (also Access 2000, call it "Language.mdb", although there is a lot of different background data in it), depending on the current user's language preference. It is unfortunately not an alternative to merge these .mdb's into one file.
To be able to show the datagrid I have so far linked the tables from "Language.mdb" into "Projects.mdb", but this screws up when the project is being installed on another computer with the .msi file i created (we'd like to have this easily packaged and installed), as the "Language.mdb" doesn't exist on the linked path on the target computer (Basically the problem here).
I can come up with the following solutions:
Force all users to install on the same path, so that the links will work (undesirable)
Use connection strings in the query as shown here on MSDN (still trying this out, but I need to work on the details)
make a post-install script that relinks the tables according to the correct path.
But I think I'm doing something wrong here. As stated above, it is not an option to merge the .mdb-files, but other suggestions to changing the database schema or whatever it could be (I'm not very experienced with databases) would be very appreciated.
To get around the 'different install paths' problem I use code (on every database load) which first looks for any back end databases in the current db folder; if not found, it asks the user to locate the missing .mdb file. Then the code relinks the database(s). Once the dbs have been successfully linked, the database saves the path and checks this path first on subsequent loads.
Well, based on the constraints that you have put on the solution. I would either go with option 2 or 3. There is not an elegant solution to this at all.
I would however, lean towards your third option, as a "one time" fix to get the files linked, so that the path between them is known, and you are not dynamically adding path information into every query.
note
I'll just mention, but I'm sure you already know this, that if you are looking at doing something like this, it just feels wrong to be doing it with Access, let alone access 2000 at this time for client deployments. I would strongly recommend additionally truly evaluating the solution and see if you can either merge to one, or possibly move to SQL Server Express or something that you could send off to the user as an installer
Is Project split, as it should be, to allow a front end on each user's computer? If so, can you not store the path on the front-end and only re-link if it changes? Code to re-link tables is quite simple, for the most part. The user can be allowed to browse for the location and the Connect property can be updated accordingly.