Concrete 5 - Cron to Clear Cache - concrete5

We have inherited a concrete 5 site and they're having a few issues with it, what seems to fix the issue is clearing the cache... Instead of doing this manually is it possible to set this up automatically via a cron job? Looking at the code I can see to call the clear cache function just calls flush::cache(); is it as simple to just create a .php file that runs flush::cache();.
I've also found these plugins, has anyone used them before?
https://www.concrete5.org/marketplace/addons/clear-cache/
The version they're running is: Currently Running 5.5.2.1

Have a look at the CacheVac addon job. https://www.concrete5.org/marketplace/addons/cache-vac

Related

What can be done to improve the speed of Meteor development tool?

I am new to Meteor. I just start using Meteor for the first time. It seems a bit slow. I am developing on a Macbook Pro with SSD. I am using Firefox, and Vim. I tend to save the files frequently, causing it to refresh the browser. It takes a few seconds for the browser to refresh. I do not have much code yet. Are you experiencing this slowness? How can this be improved? Does MDG have any plan to improve this? If I make change to a file, can we cause the browser to just reload that file rather than doing a full build and causing the browser to reload all the files? Am I missing something? Thank you!
Unfortunately, you can't do anything about it. However, the complete rebuild takes place only when you change the server side code. For any client changes, the change is almost instantaneous.
You can try some workarounds by removing some packages from meteor but they will affect debugging.
There is a great thread on this issue on Meteor's Github Issue section. You can find it here
Also, you may consider using WebStorm as it is the only IDE with built-in meteor support. May help you speed up your dev time.
UPDATE: You may try using import functionality in Meteor 1.4 to define file dependencies. Also, have a look at this package

Magnolia CMS: Cannot install module

After the fall of the server with the site entrance to the admin page redirects to install the module "Magnolia Scheduler Module". When I try to install it get the error:
Error while installing or updating scheduler module. Task 'Bootstrap' failed. (ItemExistsException: a node with uuid 54b56ea3-a89c-4736-b234-b62b63b6e602 already exists!)"
Maybe someone knows how it repaired?
On top of my head right now, this may happen when one has scheduler module jar one than once? Also I assume that, you are trying to upgrade Magnolia, It is also important to know the versions of this upgrade.
One possibility to solve it to change importUUIDBehavior in SchedulerModuleVersionHandler. Therefore, one may change the conflict strategy as they wish and hence, not hit to those exceptions anymore. However, It is also important to be careful while doing these changes.
Meanwhile, you may want/need to use https://documentation.magnolia-cms.com/display/DOCS/Groovy+module#Groovymodule-RescueApp for undetstanding what actually had happened.
Hope this helps,
Cheers

WebProfiler is not loaded on custom environment

I'm running into a very weird issue. I have created 4 environments:
frontend_dev
frontend_prod
backend_dev
backend_prod
In frontend_dev, the profiler is shown at the bottom of the page as it should be. However, on the backend_dev environment it is not shown. Upon investigation I have found out that the piece of code to load the profiler is actually there at the body end tag, however the call to get the profiler content doesn't return anything at all.
Further investigation showed that the loadProfile method failed because $this->storage->read($token) returns NULL.
I wonder what is happening, seems like somehow the storage couldn't save the profile and thus could not read it upon request?
Edit 1:
I think I know why: previously both my frontend and my backend were using the same environment (dev) and the profiler cached the toolbar content to the same place. However, now that we are using 2 environments the profiler caches the toolbar content to backend_dev but attempts to load from frontend_dev cache folder.
I have found the reason as described above, in the end for the sake of simplicity (and also other reasons) I have separated my original app into 2 apps using this guide
So far it has worked out very well for me.

Where is the rc.boot script file in AIX? Could I access & modify it under the running environment?

I want to pick up the rc.boot script file & modify something in AIX system.
How to find it out? Thanks
I would suggest not to modify the rc.boot script on AIX.
Not very many services are started at that point in the boot process - very easy to introduce something that may result in the system not fully booting.
May be replaced by updates from IBM without warning - thus wiping out your changes.
Follow the method from comp.unix.aix . This set-up or something similar to it has been used at all the AIX shops I have worked at over the last 20 years. I currently use this on 50+ servers (except it is called rc.server instead of rc.local). Placing it in the /etc/inittab as illustrated (after rc.nfs) ensures that NFS services are up and running when your script(s) are run.
Cheers
I Googled rc.boot and the first result was documentation from IBM.
It is located at /sbin/rc.boot.

Keep Drupal updated

I am trying to keep a couple of Drupal sites updated and I tired of the whole process. I recently find out about Drush and I was wondering if there is a module or a CRON command I can setup to keep the sites updated for me.
Thank you.
I can see why you would want to automatically update your site, but doing so with or without drush is not advisable.
Not all module updates are backwards compatible (eg. ctools) and not all combinations of modules work together - drush does not take this into account - it just updates regardless. Add to this the possibility that the developer of a module accidentally adds another error as he or she fixed an exiting one.
Therefore you really need to test your site everytime you update a module to verify that everything works as intended. The convenience of autoupdates via cron doesn't really outweigh the troubles if clients call you up because the site crashed.
Add this to your crontab to get Drush to update your Drupal copy everyday at 12:01 PM:
1 12 * * * drush -y up

Resources