Macrura

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.

@ryan looks like this version number may be breaking version comparisons (?) edit: nevermind... only breaks with string comparisons, not with version_compare()

If you have any modules that check for ProcessWire version and don't use PHP version_compare, but instead use a string comparison, the comparison will fail. The modules that I know of that use this are in the Selectize group of inputfields and are being updated to a new version that fixes this. UPDATE 1: All of my modules that used the bad version comparison will be updated by tomorrow. UPDATE 2: All of the Selectize modules are now updated to work with PW 3.0.100 (fixed version comparison)

you are in a subfolder? you shouldn't have that /processwire-master/ part unless you are running in a subdir does your site load the same on www and non www? some hosts let you configure that settings at the hosting control panel, and then you can only use Let's Encrypt with the www subdomain, one example is Dreamhost.

I'm using this on all new sites now.. I think it's quite stable, and maybe could be added to modules directory? thanks!

who is the host? do u have force www?

Could be browser cache?

I recently worked a lot with the import export; it all worked really well, no problems, but i had to view the json file and do some cleanup since it was a complex export/import process; Also i didn't do any repeaters; If you are careful and know how it works, and observe what @Robin S said, it should work well...

i haven't worked on this ajax module for several months so it really is not ready, but i do have a working version if you want to try it. It needs testing, and work; The screenshots show some elements of the setup in case of any confusion. ---the field--- ---the files--- InputfieldSelectizeAjax.js InputfieldSelectizeAjax.module

@Ivan Gretsky i do have an inputfield version for ajax that is in development, i think it works pretty well; i can post back here once i am able to test it again - i will attach it to the post so you can try it out.

Been looking at the issue, as i have this being used on 3 sites; none of the sites are displaying events anymore, clients not too happy ()... The module itself though is doing it's job, so nothing wrong with the module; rather, the feeds are returning an empty array; we can only assume that this is something to do with Facebook new security, however even looking through the app settings and documentation, can't see how to debug this through facebook.. UPDATE: I saw this announcement here https://www.codeofaninja.com/2011/07/display-facebook-events-to-your-website.html Guess we're waiting for FB at this point...

so one of the first things i did was change the global to g_settings https://github.com/outflux3/ProcessGeneralSettings/blob/master/GeneralSettings.module#L31 besides that i added support for placeholders, collapsed states, markup, import/export of settings.. +1, i'm super paranoid about global vars now, since i lost all of the listers on one site... not sure if this problem still exists, i may have posted an issue report on the LP thread and Ryan may have changed it, haven't checked though...\ did you encounter any problems with LP? i usually use more verbose globals for that, but on the other hand i have a new module that uses a $meta global, and another one with $theme; sometimes it's nice for the globals to be concise

My module (Settings Factory) has no relation to this module (General Settings), it doesn't share or inherit any code. Settings Factory does not set a global var for the settings (that is left to the user and how they interact with the SF api), therefore it does not suffer from the same issue which is that this module by default/upon installation sets a global $wire var for $settings, which is already being used by LP. I don't personally endorse or promote, or recommend this module – i advise that it NOT be used until the $settings problem is fixed; as i stated in earlier posts, i used it on a couple of sites, forked it and fixed all the issues, but for the last 10 months i only use Settings Factory and i don't use this module at all. It is fine with me if this module is deprecated.

Objectively, this module provides a clever interface for adding fields to your settings. My fork of it supported more fields, and other improvements. The warning here, as is mentioned earlier in this thread is that you do not want to install this module if you use Lister Pro, there is a serious incompatibility that causes your Lister Pro listers to lose their settings. Besides that, Settings Factory allows multiple settings pages (unlimited) that you can link to in your admin menus; this module would be a single settings screen only. Further, you must use the fork if you want to have the settings be accessible to non-Superusers.

Looks cool, but I'm sort of addicted to the WireRender Pattern now... https://github.com/NinjasCL-processwire/wire-render-pattern https://medium.com/@clsource/the-wire-render-pattern-806bf6d6097a