Macrura

i vote for the clear cache admin to be in TD; I do find it necessary to sometimes look at and/or clear caches in wirecache ($cache)..

you can double click the Pages item to page tree, or you can re-enable the Tree submenu item (i always do that).

Font Awesome 5 Pro for ProcessWire At Github: https://github.com/outflux3/FontAwesomePro I whipped up a font awesome pro module so that i could use those icons in the admin; it will be one of those "BYO vendor files", so you'd load your own Font Awesome 5 Pro assets once you buy it (about 1 day left to get the discounted pro license!)... Just posting this here in case anyone else ...is working on something similar ...already built something like this ...wants to collaborate on it} The webfont version basically works well in current admin theme but requires a custom css with fontface redefinition to refer to legacy 'fontAwesome' which is used in the admin css. The svg framework seems to work well, and leaving in the legacy font-awesome means that any icons that can't be replaced by JS are still visible (like :after psuedo classes); SVG framework only works with solid, probably because the new prefixing (fal for light, far for regular..) This is also going to be interesting for future admin themes, and the new 'regular' style is cute... Solid (default): dashboard example showing more icons: SVG framework:

this does work: $FieldtypeColor = wire('modules')->get('FieldtypeColor'); $field = $fields->get('dw_color'); $field->outputFormat = 0; $widgetColor = $FieldtypeColor->formatValue($widget,$field,$widget->dw_color); i just wonder if it is simpler/more efficient to do it this way: $widgetColor = '#' . ltrim($widget->dw_color, 'ff');

medkit - ok thanks, wasn't sure which one! Yes, the module does do some of the field and template installation, however so many things have to be assumed, because around 5 of the fields are page reference, so there needs to be populated items in the tree to even setup those fields correctly; i know it can be done, but would take some interaction or module config settings; right now the module config does need you to specify the root of the widgets themselves; but the other fields, like the shortcut select needs a branch holding all of the shortcut definitions; also each widget has view access settings for user, role and permissions, and for some reason those fields are not being fully setup correctly through the api; i will try and get the current version up on github soon and see if anyone else can work on it; i was also considering how to not use any PW fields or templates and make the whole thing be configurable from the module settings.

The dashboard module definitely works well and saves a lot of headaches for me as far as interacting with clients. For some reason most of my clients have an incredibly hard time using computers. I have to make everything as simple as possible; The dashboard was the only way to accomplish this, e.g. allow users to interact with a complex website, with a lot of data, moving parts, etc, and make it where they can log in and within 1 click either be editing a new content item, viewing a list of content items, recent formbuilder entries etc. The module is dependent on several types of fields, like FieldtypeColor (for the color of the widget header bar), FontIconPicker, for the icon to use for shortcuts, and Selector field for setting up the custom mini-listers. The module requires about 13 fields and 2 templates, as well as 3 page tree branches to hold the widget types, shortcuts, and widgets themselves; it hasn't been easy to port the dashboard from site to site, but i have gradually been able to automate some of the process of creating fields and templates (using some methods in the module that read the json export of fields and templates), or have used the built in export/import of fields and templates, as well as the new pages import/export. This screenshot is a simple example from a testing instance of PW.

possibly, read on... If you are comparing 'the' UI side by side, the problem is that there is no 'the' ui, because the page tree is the default UI, however when i build a site, my clients log into an admin that shows a dashboard (like wordpress), with lots of shortcuts to common areas, as well as content creation (like 'New Blog Post'). Some of these clients have never seen the page tree. ListerPro is a little bit like the wordpress listing of pages (albeit without hierarchical indents), but 'on steroids' – instantly filter to any page by title, use the filters or lister actions, edit inline, and ... bob's your uncle.

have you tried lister pro?

just a stab at this - it may depend on how the file with that code is being included; you can try a backslash in front of the AIOM and see if that works, or you can instantiate the AIOM into a variable like $aiom = $modules->get('AllInOneMinify') or whatever the class name of the module is..

awesome, thanks again, got the export working now for them...

this site is still 2.7 i'm trying to convince client to upg but complex site so need contingency budget... i'll try the old version and post back tomorrow

Hi Adrian, Having a problem with the CSV export, getting this error on the process module for exporting this table (on table version 13) Method Page::downloads_table does not exist or is not callable in this context and also getting this: PHP Notice: Array to string conversion in .../TableCsvImportExport/ProcessTableCsvExport.module:112 not sure what's going on, downloads_table is the name of the field...

aw snap - i thought i tested this on a 2.7.3 site

adding this to the multi's css file fixes it: .AdminThemeUikit .chosen-container:not(.chosen-container-active) { position: initial; } after more testing i can do a pull request to have that added to the module...

I just forked the module and added support for repeaters (only on the multi select inputfield for now); it basically involves 2 steps - changing the module code to use mostly the renderReady method instead of render(), and then some small update to the js file to init the field on the necessary events, which for the sake of brevity also involves moving the init code into its own function var... I submitted a pull request; in the meantime if you need this to work now, you can try the forked version https://github.com/outflux3/InputfieldChosenSelect

looks like i could use this module pretty soon on a project - LMK if you need someone to test it...

very nice - a good alternative to other page select options out there, and intuitive for the user;

@noelboss - have you tried using TracyDebugger yet? You could get that going and then troubleshoot the contents of the $page in the profile editor; you may also be able to see warnings and errors when using Tracy. Using it is pretty much required if you are doing any serious dev work in the backend.

1,2,3) There is a module called Hanna Code which can do most shortcode functionality you would need. Also the Oembed Textformatter can handle a lot of those things: http://modules.processwire.com/modules/textformatter-oembed/ http://essence.github.io/essence/ Spotify, Instagram, Youtube are listed. 4. In terms of building content as you linked to, that article is composed of stacked containers, so you'd most likely be building that type of content with a Repeater Matrix. 5. Gif insertion into the RTE should be no problem AFAIK. 6. I've never had any problem creating galleries; it comes down to writing code. 7. There is built in cropping and there is a Crop Image module; they both work differently. PW has the most advanced photo manipulation capabilities of any CMS, and thanks to @horst for all of his work in that area.

Frontend editing implies the native processwire functionality for that, not apropos building your own forms; when you build your own forms you can use any jquery plugins that you want, so you can just load the chosen assets and init the field on your form.

@Zeka As far as I can tell from your screencast, you are not saving again, after the params are loaded - in other words: 1) clear field 2) select preset 3) Save 4) optional, edit or view the loaded params 5) Save (again) I followed your exact steps, however as i said you are not saving 2x - that is essential to commit the settings to the database. It is not necessary to change the skin, in your step 5. In other news, the latest commit should fix the repeater problem, it was just a super simple matter of hooking into the renderReadyHook, instead of the plain render, because the repeater will actually run the renderReady on every inputfield within the repeater itself which forces the assets to load.

can't seem to be able to init the rangeslider when the ajax loads the repeater; anyone out there know how to do this? Once there is a solution to re-init the field on the ajax opening of the repeater, that should solve the first issue. in terms of the 2nd question, are you saving again after loading the params? everything works correctly in terms of preset loading here, and not needing to change the skin; can you confirm if you saved the field after loading the new settings?

ok thanks for the reports, i will work on the repeater support and also troubleshoot the loading of settings... will post back asap.

@Zeka ok i changed the javascript, it works here in test environment in repeaters, let me know if it works for you..

put the src on the video element, not on the nested source element - the js is setting the src on the video element, not the video's source element