Jonas Erlandsson

To me that sounds extremely cluttered and making the tool more cumbersome to work with. I guess that boils down to level of knowledge. At one point that kind of help just becomes a distraction. If applying such a strategy would be on the table I'd ask for a setting where it can be turned off. I wish this was true, but in fact the documentation is a mix of API docs (classes and params), while other pages are guides on how to do things. I'm a developer since 2008 and still find this extremely confusing. I can start reading an article on how to do X, which gives me a link to Y, and when I click on Y it shows me a class description, but it doesn't tell me how to actually use it. It takes for granted that I know where to put the file. It would be so much better to completely separate these two types of documentation and have guides/tutorials in one section and API explanations in another, and reference to them from the guides by explicitly calling it what it is. To me it's even come so far that I don't really use the documentation at all, but rather debug the application to understand how things work under the hood. And that's something I really shouldn't have to do. When I've asked in the forum I don't get any pointers either. Instead you insists on getting direct access to the server to be able to check. I don't want the support team to log in via SSH to my server to check the installation. That's a huge security risk. I want to fix it myself by getting pointers where to look so that I can 1) fix it and 2) report back to you what the error was. If you need to have 100% control over your installation in order to give support you shouldn't sell the on-premise at all. Even if this isn't 100% related I think it's important - when building stuff I need to enable some dev-mode in order to generate some file structure, move over to my editor/IDE and code, then go back into the Developer Central to create some other thing. The entire developer experience is throwing me between my editor/IDE and the ACP. I would highly recommend creating a CLI tool where I can work without the disturbance of switching to the dev central to do things. This workflow feels like a 2003 type of standard that no one really works by anymore. It feels like you're living in 2012 with no real desire to move into 2022. Hell, you're still even using jQuery.

I think it would be a really cool idea to have a deep diving guide that starts with how to build an application with all its' bells and whistles (not just a text dumping out Hello World), such as menu integration, view files and JavaScript shenanigans. That application could then serve as a base for a guide on how to build an extension, a plugin and whatever module type you might have. That would obviously be a big job, but I think that would be a great way to educate people on how to work with your product. In the end that could help bring the need for support down because it would make it easier to debug things on your own as long as you have a the basic understanding about your platform, since the main applications follow the same principle. Does that make sense?

I'm quite new in this world, but I, for one, would love some more in-depth examples/guides on how to create/extend the platform. What we have now is the extremely basic Hello World application example, which doesn't cover how to work with the JavaScript framework (it's linked to some other JS framework page that is more of an api documentation than examples), neither does it explain how to work with the menu system. Literally all it does is showing the text "Hello world". When I've been following guides (i.e the release-notes guide) the active page navigation often disappear so that I have to find the right section in the sidebar, open it and one or two more steps to find the next page. Linking to the next page at the end of the section would be a very easy and welcome addition. It might not be a really big issue, but that sidebar is really cluttered with links making it a bit cumbersome. Regarding support in general I must say that @Marc Stridgen has been really quick to answer my questions in the forums.

Now everyone is back from the winter holidays and I've talked to the head of operations. We would need a time slot for when you would log in and a list of IPs that should have access. Is that doable?

Ok, I'll see if our devops team can sort it out. I'll get back to you when I've got an answer.

The information is updated. Unfortunately I can only give you access to the ACP. And please do _not_ press the clear cache button as that's our production (it might speak for itself at this stage but better safe than sorry 😝)

The system has created them and I can upload files in the system. The system can create files so it should be able to create folders (e.g uploads is writable by the system). It still won't recreate. That's why I want to debug why things aren't recreated. As I mentioned earlier in the thread I changed the index.php file so that it would create things in the uploads folder when I load the page and that worked so files can definitely be created. We've even had 777 permissions on the uploads folder but it still won't recreate it. Can you point me to where things are being recreated so that I know where to start debug without having to trace it manually please? I'd be happy to share my findings here so it'd be a win win for everyone.

We've figured part of this out now. The system cache still breaks stuff but at least it won't kill the theme anymore. However - it does not recreate the upload-folders that keeps my images for my CMS content so I had to manually re-create that again. I can re-upload the files. I had a monthly_2021_12 folder containing content and when I run the clear system cache that got removed and not re-created. Can you point me in the direction where the system cache gets recreated after clearing so that I can debug it? Now it acts as a "remove all uploaded content" to me rather than a cache clearing mechanism.

It does say this: What does the "support tool" refer to here and is it triggerable via REST? I looked up the clearCache controller and that doesn't seem to regenerate the files again after being run (but maybe that's done when the site is loaded for the first time?). I even tried to change it so that the cache would be stored in the DB but that had no effect at all. I edited index.php and tried to write to /uploads when I loaded the page and that worked so the application can write to the uploads folder. Any ideas @Marc Stridgen?

Is there any way that I from CLI can rebuild the things that the system cache deletes?

I do have a lot of template_<hash>-files in uploads (and some in the datastore folder as well). The uploads folder also contains css_build_0 and whatnot. So the directories are writable. Trying to turn on debug logging now to see if I can get a more detailed error. The uploads/logs doesn't give me any kind of error strangely enough.

Hello. I've moved my installation from one server to another and if I copy the datastore and uploads from the old server to the new one everything works, but since the old site is our staging/test-installation the domain is different and things are loaded from that old domain on the live site (which gives me cors error). So what I did was that I tried to clear the system cache and when I do that all hell breaks lose. All CSS and JS are gone (e.g not reproduced in /uploads) and all I see is: InvalidArgumentException: (0) #0 /site/system/File/File.php(326): IPS\_Image::create() #1 /site/system/Theme/Theme.php(709): IPS\_File::create() #2 /site/system/Theme/Theme.php(4495) : eval()'d code(14): IPS\_Theme->resource() #3 /site/system/Theme/Theme.php(5348): IPS\Theme\css_core_global___flags_css() #4 /site/system/Theme/Theme.php(2543): IPS\_Theme::writeCss() #5 /site/system/Theme/Theme.php(621): IPS\_Theme->compileCss() #6 /site/system/Dispatcher/Standard.php(63): IPS\_Theme->css() #7 /site/system/Dispatcher/Admin.php(89): IPS\Dispatcher\_Standard::baseCss() #8 /site/system/Dispatcher/Dispatcher.php(110): IPS\Dispatcher\_Admin->init() #9 /site/admin/index.php(13): IPS\_Dispatcher::i() #10 {main} and it looks like this: any ideas on what might go wrong with this? My first thought was that uploads and datastore couldn't write, but when I look in there I can see that new files have been created. I seem to get 500 error (in network tab) when I try to go to /admin.

We switched out the base docker image to another one where we got the same error, but after we let nginx "understand" the what the domain is, it started working. In nginx you can set server_name to be _ which works as a catch all, but this didn't work.

@Marc Stridgen Now the site is temporaily available. Could you try and login? Note that adminCP works but not the other login. Thanks!

The test URL is registered in my client area, but I'm thinking that you probably need an account too, right? Could you point me to where I can edit these access details? Sorry, I'm a rookie 😬