Macrura

depends on if you are appending a _main.php file; you can also disable that behavior on the template settings; or do it using variables in your templates; As far as I'm aware, generally return $this->halt() is now recommended over exit() but may not work in 100% of scenarios so exit can be used as a contingency...

I don't think I fully understand the setup; does your module create a template that it uses - you could just create the template file in your /templates/ directory and then wireRenderFile() the file in the modules from that; but i'm really not clear on the setup so hard to answer coherently.

wireRenderFile() ?

you can either use the template class or just wireRenderFile() which uses template class – see dashboard module for an example...

yes, since you create the inputfields, they support all built in attributes, so you'd just need to set those attributes in your PHP or JSON array. Yes, each settings page is full access controllable.

what PW version, did you try force reloading to get the CSS to update?

Not sure, i doubt it, but i use Colorsnapper on Mac which lets me pick colors from anywhere on the screen and then i paste the value into the colorpicker field hex

have you tried logging the POST request to both the URL and the URL with the Segment - it should be the same unless somehow URL segments are not activated on that template. The idea should work, I can't think of any reason why segments would not work on an ajax service page; if you keep hitting up against issues you could go for query parameters instead. You may also need to check if there is a URL segment present, like if(strlen($input-urlSegment etc.. ; and make sure to also do the regular sanitization of the $input, as well as return 404 for unused segments...

InputfieldSelectizeMultiple or ajax version – the ajax version was designed for this purpose you describe; non-ajax version has only been tested to work on maybe 500-600 select items

whatever version i'm using works great and has the option to use files and not pasted code, in the field config.. i thought it was the dev branch.. very stable and i have it running on 5 projects now, basically this is a completely indispensable module, i usually end up with on average 10-15 RM fields on any given project..

why?

it always works for me – did you add a general-settings permission and then add that permission to the role you want to have access to the settings? I will also check this on my last install to double check, but yes, it is supposed to work, that's why the module was re-written as a split module with the process.

@Noel Boss see the dev version

yep, built a new customac so up and running ( submitted 2 modules today)... this is a tricky one though (lot of fields to make a useful working dashboard)...

neither, content is in database

@chcs have you seen this post?

or maybe we should leave the modules directory as is, and then make the Process module install the other module? I guess that would solve this – so i just need to move the "installs" configuration setting from the non-process to the process...

This has been tested and here are the results: (1) You cannot install this module from the modules directory – the directory needs to be updated to use the primary module class name, which is GeneralSettings, that would presumably fix the issue, because it would download the whole package, and then install the accompanying Process module, after installing the primary non-process module. (2) there was an error in the main module, in that it was set to autoload false; it needs to autoload in order for the init() function to load on the module config screen, and consequently load the required JS and CSS. (3) There was a return statement executing if there was no saved module config data; this would cause the module to appear to not work, as the required JS would never load (it would have worked if you saved the module once). The asset loading was moved above the possibility of return statement executing so the JS will always load. (4) The only tested admin theme that appears to work is Reno; else things look off... will have to be fixed and tested on the other 2 admin themes. Since I do not have access to edit the module, i edited my repo and then I submitted a pull request to @flydev Once he accepts the changes and the modules repository updates, the module should be in a working state. Note that the reason you want to have a separate process module for your settings is so that you can allow access to the settings screen to non-Superusers. The old module version is going to be a problem for a lot of setups where you expect to provide settings to your other admins.

Do you mean in the admin page edit? If so, Page Select doesn't support markup, you'd need to use InputfieldSelectize to get a formatted option with an icon.. If you mean in the admin menu, not sure about that...

OK i will check it (no power here at the moment) so may take till next week to test as you have outlined the issues.

Noting here in case anyone has attempted to use any Selectize inputfield with the AdminThemeUikit, there are some known issues. (1) the latest versions of InputfieldSelectize should work, meaning you should see selectable options now. Prior to the latest version, the single select inputfield didn't work, and the uk-select class had to be removed from the field. (2) Selectize Multiple works, but is slow, and almost non-functional if you try and filter options. This is a major problem, and I have no idea how to fix it; there must be some javascript being triggered and going into a loading cycle when on Uikit, as opposed to Reno or Default; It is assumed that Selecize single would also suffer from this when filtering, but I haven't tested that yet. If anyone know how to test or determine what the cause of Uikit not working right with Selectize, it would be greatly appreciated!

@flydev done

@pwfans i have it running well on a large PW3 site. Did you run into some problem? I didn't need to add any namespace or do anything in particular, it just works.

I would probably have used 1 page per image model, and not the image extra; though if it works and you like it, then that's great. I just prefer the wider control afforded by use a page for an image, in terms of exactly the problem you are describing...

Latest version of all modules have the fixed version compare, and the inputfield now also has the Ajax version included, but that one is still beta; it is largely a copy of the core inputfield, so shouldn't exhibit any errors, but may need work to make full use of the possibilities.