I added in my system.xml a new config data, and it is working well in my developer server. It is inserted in db Core Config Data.
However, on production server, my config isnt in Core Config Data.
Of course I cleared cache, refresh everything several times. Nothing changes.
Is there a cache file somewhere for this config that I have to delete manually?
Edit :
I saw this, Magento Core Config Data Cache but I have not rights on all /var folder, so I will need to know the exact place of this cache
Related
Anytime my app goes to sleep and comes back on, I lose data in my database
And I'm not storing any media, it's just form data (texts)... I built the app on strapi and I've followed all their guidelines but it keeps happening. I'd be happy if anyone can help
Local data (files, db) is cleared after a Dyno restart because the Heroku File System is ephemeral. A Dyno is restarted (at least) every 24hrs.
In your case Strapi uses SQLite where data is saved in a local file.
Strapi suggests to configure Postgres on Heroku, alternatively you can use an external DB storage service.
First of all:
As you create content types with strapi it generates the code (= new files) for the according controllers/routes/services
Heroku does not persist data after a restart
After a restart strapi checks which content types exist in the code and deletes the tables of nonexisting types from the database.
Therefore, on Heroku you have to set up all your content types locally and connect to an external db (e.g. Heroku Postgres) but never strapi's default textfile based db.
Then push the generated files and finally deploy.
Thus, on Heroku you should always run in production mode. This way the option to alter content types is completely blocked and you will not run into the issue of data loss after a restart.
I have implemented a Sitecore custom cache which works fine on my local instance. I have pushed changes to production (in production we have 5 CD servers which are served through a load balancer). When the first request is made the code fetches some data from DB and cache it. If the same request goes to other CD box the previously fetched data is not available in the cache!
Can someone help on this? Do CD servers not share the cache across?
This is the expected behaviour of the in-memory cache what works well for single-server deployments only like your local instance, but when you have multiple CDs each of them has its own local memory cache store not shared with others.
Therefore, for scaled deployments, you can use the Redis Cache as a centralised cache store, so that each CD role can access that cache store and retrieve the cached data.
Redis Cache is verified by time and works well when synchronising data updates between multiple CDs.
been struggling with setting up Umbraco on a development machine and test server...
Both environments connect to the same database and I use uSync to keep all my changes in git, however mediafiles are a real p.i.t.a.
I started off by adding media on my dev machine and copying over the media folder when publishing to test. Not very elegant so I tried using the rootPath and rootUrl in the filesystemproviders config. Path points to a network file share and URL to a dedicated virtual directory hosted on a media.test.mysite.com subdomain.
Surprise ... when opening the site the old media is vanished because umbraco saves the absolute path in the cmsProperty tables {'src': 'http://media.mysite.com/1041/...' }, previously the relative path when configuring the virtualRoot.
I'd like to alter the composition of the media url's in both front-and backend. Define a media_root appsetting holding the hostname, protocol and port (http://media.test.mysite.com) and prepending this to the src stuff that comes from the DB...
Any suggestions?
I already tried a custom URLProvider but this only works for non-media content ... it seems :-|
Thanks!
Y.
I'd recommend using the Umbraco File System Provider for Azure which will upload your media to Azure Blob Storage. You can then use the disk cache that comes with ImageProcessor.Web (included in Umbraco Core) to cache the files locally. We run our dev environments pointing to the same blob storage as other environments - so no need to copy the files. And the references are relative (/media/1001/file.jpg) when using Disk Cache thanks to the HTTP module in ImageProcessor.Web which caches them to disk. (You could alternatively use the ImageProcessor Azure blob cache plugin and have the images load from Azure. You might want to check out this documentation at Our.Umbraco.org (even if you aren't using Umbraco Cloud).
I am trying to set up a copy of a Magento site for development use. I have copied the code from the server and grabbed a copy of the database.
I setup Apache, PHP, redis, MySQL, php-curl.
I added the DB user with all privileges and imported the DB.
When I load the Magento site up it loads with the default theme. Going to System > Configuration > Design shows it has defaulted all the options and they are not what they are on the live site.
Where is this configuration stored that it wasn't copied with the rest of the data? Products are all there etc, it just seems to be system configuration like cache enabling and theme etc.
The problem came down to the DB export script which wasn't including data for the core_config_data table. After doing a manual export myself the site had all its options.
I have a Magento site running on a live e-commerce server.
I downloaded the whole site for offline use in a development environment. I changed the Base URL values in the database and edited the local.xml file but my local development site is still referring to the online store.
How do I correct this?
The usual problem, changing your base urls and local.xml is only a minor part of the equation.
Step 3 was missed on moving the website to the development server.
Moving stuff is actually pretty darn simple.
a. Tar the public_html directory on the old server
b. Reinstall on the development system.
a. Disable caching in Magento on the old server, dump the database and then reenable the Magento cache.
b. Create a mysql database, user and grant permissions on the development system. Load the database dump into the database on the development system.
Do the one thing that most people ignore, go set your file permissions and ownership.
Change your base URLs using either mysql command line or phpMyAdmin.
Go eliminate every subfolder in the var/ folder, Magento will recreate it.
Finally, go make changes to your local.xml file to change the database access credentials assigned to the new database and bring Magento up.
If you have complete ownership of the server, do the above steps with the Apache server down until you've loaded all the data and made the permissions and file corrections. This prevents accidentally starting Magento in an unprepared state which can cache Magento's configuration which is why you are having this problem.
If you do not have proper permissions on the var/ folder and subfolders, Magento will write your Magento temporary and cache to the system temp and you end up with Mage's magically redirected Magento which eternally points to the original website.
Also, if you copy local.xml to another file to save it, name it something like local.xml.sv0 otherwise if it ends in .xml, Magento autoload each .xml file in app/etc/ and try to merge it with the contents of your local.xml file.
NOTE: What happens when you don't properly set file/folder permissions before running Magento for the first time after a move.