theoretic

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.

Thanks adrian! Another great idea from You! It seems You know Your module much better than me, so You'll be faster to add one more action. However i can try to do it in a couple of days.

OK, have some hours spent to resolve the problem. Conclusions: It's possible to clone a repeater item using API,.. ...but it's a delicate procedure which can be performed in the only correct way. Trying to use alternative approaches may even corrupt your database (thanks again to the PW creators for making a very simple and straightforward DB structure which can easily be healed if corrupted!) My way to clone the repeater item from one page to another: //Creating a new page which will hold the repeater clone $newPage= new Page(); $newPage->of(false); $newPage->template = 'my_template_with_repeater_field'; //Setting some more fields skipped ... //Getting the original repeater item $repeaterItem = $pages->get("some_selector=$some_value"); //Saving the page before cloning the repeater -- it's very important! $newPage->save(); //OK let's clone that repeater item now! $repeaterItemClone = $newPage->repeater_field->getNew(); //the repeater clone is already created and saved to the database //Cloning the repeater fields $repeaterItemClone->field1 = $repeaterItem->field1; $repeaterItemClone->field2 = $repeaterItem->field2; //Cloning some more fields skipped ... //Saving the modified clone $repeaterItemClone->save(); Maybe it could be useful to create a PW module for cloning repeater items. Hope this will be useful to someone

Thanks everyone for a perfect product! Got a problem during development of a website which has two different templates sharing the same "suboffers_prices" repeater field: the "offer" template and the "order" template. The idea is to take a single repeater item from offer page and to save it as a repeater item to a newly-created order page. Getting a single repeater is not complicated: $suboffers_prices = $pages->get("uid={$input->post->suboffers_prices_uid}"); But saving that suboffers_prices to a new order page appeas to be not that easy: $newOrder->suboffers_prices = $suboffers_prices; $newOrder->save(); //doesn't save the repeater ...another try... $newOrder->suboffers_prices = $suboffers_prices; $newOrder->suboffers_prices->save(); //in fact saves nothing ... $newOrder->save(); //doesn't save the repeater ...and another... $newOrder->suboffers_prices->getNew(); //$newOrder->suboffers_prices->of(false); //not callable in this context, PW crashes with error $newOrder->suboffers_prices = $suboffers_prices; $newOrder->suboffers_prices->save(); //again saves nothing ... $newOrder->save(); //again no repeater saved Tried some other approaches, still no result. Would like to get any advice on the best practice for saving a single repeater item to another page. Thanks in advance!

Thanks again justb3a! You're the best