theoretic

@bernhard sorry, i though You mean the design approach not the technical realization. I just did some auto-replacements in /wire/modules/AdminTheme/AdminThemeUikit/uikit/dist/css/uikit.pw.min.css . The better way will be to do the same with /wire/modules/AdminTheme/AdminThemeUikit/uikit/dist/css/uikit.pw.css and then to minimize it using Your preferred tool.

@bernhard , thank You ! It's nice to see that i can do something useful for the community. I clearly understand that anyone can have his own preferred colors, but the convenience and positive UX can be achieved if we will accept some simple design rules. Consistency. Any color, any font variation should have the same meaning across the whole app. E.g. every link should be blue, every visited link should be grey and so on. The current AdminThemeUIKit has no major drawback of this kind. The link and button colors should mean what they mean in common. The blues and greens are the metaphor of something positive, greys are neutral, light greys are about something disabled and/or inaccessible. As for reds -- they're commonly threated as a sign of risk and a metaphor for dangerous actions. Here lies one of the important drawbacks of current AdminThemeUIKit . Every link is red -- why? The "positive" buttons like "Add new something" become red when hovered -- what is the reason? Okay, we humans are able to quickly adaptate to almost everything. But adaptation always means discomfort and perplexion. High contrasts and bright colors are for wow effect only. Admin interfaces need the light, moderate-contrast and calm appearance. The current color scheme of AdminThemeUIKit has the major drawback of high contrast and bright colors. Details are below. The bigger area we fill with color the less bright and less saturated this color should be. Just imagine the AdminThemeUIKit's header totally filled with red: it will be extremely annoying. The current almost-black header fill is also far from being ideal. Too dark, too saturated, too much contrast with the rest of the page. This big area needs a light, low-brightness, low-saturation filling. On the other hand, the textual links deserve the bright and highly saturated colors (but not reds please, at least for "positive" links). Hope this will help. And thanks again for a perfect product!

Thanks Adrian! Works like a charm. Maybe this deserves to be added to docs.

Hi there! And thanks for Processwire. Got an interesting question: is it possible to programmatically get the default value of SelectOptions field? Getting all possible values is not a problem, but docs can say nothing about getting the default value. Thanks in advance!

Since no one tried to revive the "oldish" UIKit theme -- i did it. Moderate contrast Non-aggressive color scheme Light colors, no dark backgrounds Very close to the original UIKit design Feel free to replace the /wire/modules/AdminTheme/AdminThemeUikit/uikit/dist/css/uikit.pw.min.css with the file i upload here. Hope it will be useful for community.uikit.pw.min.css uikit.pw.min.css

Hi there! And thanks for Processwire! Just upgraded one of my PW sites to the new core-integrated UIKit admin theme and feel a bit confused. The "old" UIkit theme was in white and blue colors, rather minimalistic and very convenient for intense work. The current color scheme is less convenient: darker colors, rough contrasts. Okay, it's just my personal opinion -- but having possibility to choose different color schemes could be a good idea for this perfect admin theme. In plus, there's no need to build the "white-blue" theme from scratch -- it was already a part of UIkit admin theme recently. Thanks in advance!

@netcarver, thanks! Works now.

@Macrura, think that wire(‘settings’) doesn't work, at least if we deal with PW 3.x and ProcessGeneralSettings. Your approach gives the error: Error: Function name must be a string

@adrian, thanks for that! Didn't know about that module. I'm rather impressed by @Macrura 's work, but currently it's a bit overkill for me. The only thing i needed beyond the standard ProcessGeneralSettings functionality was the ability to save the changed settings. By the way, is there a possibility to access $settings from inside functions, modules etc?

Hi there! And thanks for Processwire! Would like to propose an extension of this module. Sometimes it could be very convenient to update settings dynamically and then to save them. A practical example: currency rates for a multi-currency shop. It's logical to store rates as general settings. But it's also logical to make a script which gets the actual rates from external website and then re-saves them. Some mockup code: $currencies = ['AUD','GBP']; $currencyRates = []; //getting currency rates skipped foreach( $currencies as $currency ) $settings->$currency = $currencyRates[$currency]; $settings->save(); Unfortunately there's no save() method in the original ProcessGeneralSettings.module , so i had to write it: public function save() { $old = $this->data; $data = json_decode($old['settings'], true); $new = array(); foreach ($data as $key => $field) { $new[$key] = $field; $new[$key]['value'] = $old[$field['api']]; } $old['settings'] = json_encode($new); wire('modules')->saveModuleConfigData($this, $old); return $this->data; } Have tested it, works like a charm. Would like to merge it into the official module.

Hi there! And thanks for Processwire! Another bug found for fields of type FieldtypePage. There's a "custom find" section in the "input" tab allowing to select several conditions for finding pages which will be included into thepages listing. This feature doesn't find any page. Tried to use "template" and "id" conditions, always no result. Fortunately, the "template + additional templates" section works fine. My PW is 3.0.77. Hope that helps, and thanks in advance!

@fbg13, thanks a lot! Worked like a charm.

Hi there! And thanks for Processwire which i like very much. Got a problem while trying to update from 3.0.65 (with admin theme UIkit ) to 3.0.78 . Tried to do it both via ProcessWireUpgrade module and by copying/replacing the files and dirs manually. In every case i got the problem with UIKit admin theme. The first try to reload any admin page after update gives the following errors: Notice: Undefined variable: adminTheme in D:\work\sites\home\sea.dev\webroot\site\modules\AdminThemeUikit\init.php on line 121 Fatal error: Call to a member function get() on null in D:\work\sites\home\sea.dev\webroot\site\modules\AdminThemeUikit\init.php on line 121 It is officially recommended to reload the page several times after update to get the admin interface functional again, but it's not my case. The problem still persists. It's obvious that $adminTheme is not initialized. Reverting back to /wire dir of version 3.0.65 removes the problem. Switching to default admin theme and then updating to 3.0.78 makes the admin interface fully functional -- but switching to UIKit admin theme leads to the error again. Will appreciate any help. Thanks in advance!

Hi everyone! And thanks again for a perfect product. It appears there's a small bug in the implementation of fieldset. If we rename a field of type FieldsetTabOpen, the auto-created field of type FieldsetTabClose won't auto-rename. E.g. if we create a fieldset called "noises", two fields will be created -- "noise" (type: FieldsetTabOpen) and "noise_END" (type: FieldsetTabClose). And when we later rename the field "noise" to "acoustics", the field "noise_END" still keeps its name. The auto-generated field description will also remain unchanged. This is only a minor bug, but removing it could make the Processwire even better. Thanks in advance!

Hi there! And, as always, thanks for a perfect product! Would like to discuss an interesting case. Let's suppose we have some images attached to different pages, each image having some extra fields including uid field which is unique. We have to build an api page which should receive requests like /api?uid=efv97yg and it should return some JSON about the image with that uid. Is there any possibility to find an image by its extrafield value (e.g. uid)? Well, i know that we can do something like this: $pages_ = $pages->find('template=page_with_fotos'); foreach($pages_ as $page_) { $images = $page_->images; foreach($images as $image) { if($image->uid !== $uid) continue; $json = json_encode($image); break; } } echo $json; But its not very elegant. And even worse: $sql = "select * from field_foto where uid=$uid"; $query = $database->prepare($sql); $query->execute(); ... What is on my wishlist: //pseudocode, will NOT work for sure! $foto = $field_fotos->get("uid=$uid"); ... Will appreciate any advice. Thanks!

@szabesz , thanks! Did it.

@arjen , grab that! The whole module is not so long, so it's possible to place it right here. @ryan , if You'll have some time, please review my mod. It will take a minute, the mod is really simple. Thanks in advance! ImportPagesCSV.module

Another nice module for PW, thanks @ryan ! Tried to use this module with PW 3.0.55 , no problem, it's compatible. Also did a small mod which enables basic support for FieldtypeMapMarker (lat and lng only). Will share my code if it's interesting for someone.

Hi @LostKobrakai ! Migrations are a great idea. But i had a trouble while trying to use it. My setup: PW 3.0.55 Uikit admin theme Tried to create a test migration and, after defining its type and description, got a PHP error: Error: Call to undefined function wirePopulateStringTags() (line 70 of \site\assets\cache\FileCompiler\site\modules\Migrations\Migrations.module) Need help. Thanks in advance!

Thanks @LostKobrakai and @diogo ! Very reasonable thoughts from you both. Agree that creating a whole new logo could be too radical. But the problem with non-uniqueness still exists. Maybe we need to do some facelifting to the freshest logo included in uikit admin theme. Will think about. @diogo , thanks for the link to the very interesting thread about PW branding, didn't read it before. @LostKobrakai , special thanks for Your opinion about the main PW website. It works like a charm but is a bit outdated from the point of view of visual representation. Can try to draw some sketches on the subject if there will be some interest from the community. Anyway we need to discuss all that because PW is an amazingly powerful and simple tool which truely deserves to be widely known and to have a better brand than now.

Hi all and thanks again for a perfect product! I'm glad to see Processwire growing and becoming a strong, popular product. The new look of admin interface (uikit-based) is nice and minimalistic. Maybe it's the starting point to think about the consistent identity for the whole Processwire project. The only thing which is more or less consistent now is the main Processwire color. Somewhate between red and maroon, I call it "Thai color" because it's very popular in Thailand. You meet this color at almost any page related to Processwire, and it's good because this color is very distinctive. But what's about PW logo? There's no consistency. And, i'm unhappy to reveal it, the PW logo (at least the sign, not the text part) is not absolutely original. There are at least three different Processwire logos: The text part of logo at PW homepage (and pure-textual logo in most admin themes, e.g. Reno). The sign part of logo present at PW homepage. The new logo (only sign, textless) present in the new Uikit admin theme. For sure it's too much. A single, unique, consistent logo could be better. As to the sign -- small b in circle -- just look at Beats Audio logo which is very similar. And even worse: there's a CMS which is very popular in Russia and called Bitrix, and it has a very similar logo. So i would like to propose another vision of PW logo. Unique, original, but being inherited from current PW logos. It's only a first approach, will be glad to polish it in case of positive feedback. And thanks again for a great product!

Thanks a lot Robin S! Will use almost all of Your solutions in process of "progressive development". Step 1: a repeater with all available Offers for any Place, editors are responsible to enter the correct data. Step 2: a hook which restricts Offers after saving the Place. Step 3: Some custom JS.

Hi there! And thanks for Processwire which i really like! Got a specific repeater-related question which i couldn't resolve. Will appreciate any help. Let's imagine we have Places (pages), Offers (pages) and Partners (PW users). Any Place can have many Offers attached to it via a repeater field. Any Partner can have many Places (repeater or a multiple-value field). He can offer some Offers at each Place he is attached to. His Offers for any Place should be selectable only from Offers already attached to this Place. Partner-Places-Offers management should be performed in admin interface via PW input fields. The ideal solution which i imagined could be a "dynamic" partner_place_offers repeater where multiple Offers for a single Place could be selected from dynamically built list dependent on selected Place. But it appears that PW doesn't have such functionality yet. Thanks in advance for giving some idea on the subject!

Hi there and thanks for a perfect product! PW seems to get more and more popularity, and its flexible power begins even to rival the frameworks like Laravel. I really like PW, and that's why i see some ways to make it even better. Frameworks are often installed OUTSIDE the document root. There's a lot of reasons to do so. Some of them: Security. Every piece of code placed inside docroot is a potential security breach. So we are to keep only a minimal amount of code inside docroot. Website engine obfuscation (and more security again). Anyone can check for presence of /site and /wire folders via http -- and if they're here then it's a Processwire inside webroot with almost 100% probability. Possibility to share the same codebase between several websites placed at the same server (it's really cool!). A nice opportunity to create a static site generator (and PW has it all to become such a generator with minimal coding). But, unfortunately, it's not the case for PW right now. PW is currently designed to be placed only inside webroot. And there's no clear way/guideline how to move PW to an arbitrary directory outside webroot. At least i couldn't find any. OK, there will be however some obvious problems while moving PW outside webroot: Many hosters deny ftp/ssh access above webroot. So it will be impossible to upload/download anything inside /site (at least using ftp/ssh clients). There will be some confusion/ambiguity with /site/assets/files . In most cases they should be accessible via http, so they need to be located inside webroot. But, hmmm, what about 'special' files like hi-res images which are to be protected from occasional downloads? Yes we can write some .htacces to protect them -- but placing such files above webroot is a better practice. Tried to 'bruteforce' my idea by moving /site and /wire from fresh PW 3.x installation one level up my webroot and applying some tweaks to /index.php . No success at this time. Had some core-level errors. PW seems to dislike my experiment, core changes are needed. My whishlist? A possibility to define path (absolute or relative to webroot) for /site (except /assets) and /wire during installation and/or after it via config.php file and/or something like $config inside /index.php . A possibility to separate /site/assets into /webroot/something_like_public_assets (this path should be configurable) and /outside_webroot/something_like_private_assets (this path, of course, should be configurable too). A possibility to change/configure paths after installation. Hope this idea is really important for the future of PW. Will be glad to see a deeper discussion here.

adrian, thanks a lot! Got my own solution working, however Your help was very useful.