December 8, 2014 in Feedback
I was wondering if there will be any external tools for advanced users, similar to how we have the tools directory in the .zip for 3x (I note its now moved to the MP though)
I was thinking of something to externally rebuild caches and templates if required, as if the ACP is inaccessible this is rather tricky.
Caches are not the same in 4 as they were in 3. There are two concepts:
Both can be rebuilt simply by emptying the store and the system will automatically "rebuild" them on demand. For example, to clear the cold storage if you are using the file system storage engine, you can just delete the contents of the folder.
Because of this, there is no need for a script like there was in 3.
Ah I see now thank you. The ISE I had experienced suggested (initially) a template type error upon examining the logs but also effected the ACP too, unfortunately I don't have that board in its exact state now to re-examine it and a localhost test upgrade using the exact same fileset (early B1 to B3) did not break.
Update: The newer build (I must of had an earlier one I'd guess, filename different) and it was OK, decided to cheat a bit and set the versions back to B1. Anyway all OK now.
Have to assume it was a bizarre bug, although I'm unable to reproduce it again.
I encountered that issue when I had completed a test upgrade from 3.4.7 to 4 beta 3A (that encountered some issues along the way).
First I tried to run the support tool from the ACP, but that was really hard due to the lack of CSS and JS. So I did a slight temporary change to the support tool in the ACP so it would run only by me visiting the support tool area in the ACP.
File: www/applications/core/modules/admin/support/support.phpAfter I had changed it, I added the line $this->_clearCaches(1) (Not sure if the param was correct, but I just improvised)
public function execute()
\IPS\Dispatcher::i()->checkAcpPermission( 'get_support' );
But that didn't solve my issue.
Then I had a chat with @daniel-son and he said the same as @Mark here, that it should rebuild when files on storage were manually deleted.
So I tried to delete css_built_1 but that didn't resolve it either. I just ended up with no CSS being loaded at all (as opposed to before I did it, where there were some CSS that had loaded).
After quite a bit of research into methods I could use, I finally found a solution. I called upon the method \IPS\Theme::clearFiles(1); in index.php. (From the file www/system/Theme/Theme.php)
Like so (index.php)
$_SERVER['SCRIPT_FILENAME'] = __FILE__;
Then I visited to the front end once, and then did a new refresh. It was now magically solved! On the next refresh I could finally see both the front-end and ACP with all the CSS and JS loaded.
I may have placed it after run() to, I'm not entirely sure now. Once again I was unsure about the parameter, but I just improvised. @daniel-son told me later that "1" apparently just meant templates, while something like template (1) + css (2) would require the param to be "3". Either way, it worked for me with "1".
That sort of makes a point then I guess in that file edits should not be needed to rectify this.
Apparently it should work to delete the files though, but it didn't for me.
@Mark, could you maybe answer as to whether that would be a bug then or whether I was supposed to delete something other than the css_built_1-folder?
Either way, it really made me love the auto-loader. Because I could just "magically" call a method from a "random" class as easy as adding a single line to index.php! Didn't have to worry about requiring a file in a certain way, manually copy a method or something. It just worked!
Deleting the stored files should cause them to be rebuilt. There was an issue with how this is handled for theme-related files which will be fixed in the next beta
And yeah, isn't it awesome? Just include init.php and you're away
This topic is now archived and is closed to further replies.
Started 21 minutes ago
Leon de Graaff
Started 1 hour ago
Started Thursday at 11:34 AM