horst

My personal opinion is: this is uggly code, hard to read, hard to maintain. I would do it more like this: switch($switchColor) { case "Style3": $cssLink = AIOM::CSS(array('styles/style1.css', 'styles/slider.css', 'styles/style2.css', 'styles/style3.css')); break; case "Style4": $cssLink = AIOM::CSS(array('styles/style1.css', 'styles/slider.css', 'styles/style2.css', 'styles/style4.css')); break; default: $cssLink = AIOM::CSS(array('styles/style1.css', 'styles/slider.css', 'styles/style2.css', 'styles/normal.css')); } echo "<link rel='stylesheet' href='{$cssLink}' />"; To be honest, it could be made a bit more readable: $myStyles = array('styles/style1.css', 'styles/slider.css', 'styles/style2.css'); if('Style3' == $switchColor) { $myStyles[] = 'styles/style3.css'; } else if('Style4' == $switchColor) { $myStyles[] = 'styles/style4.css'; } else { $myStyles[] = 'styles/normal.css'; } $cssLink = AIOM::CSS($myStyles); echo "<link rel='stylesheet' href='{$cssLink}' />"; // ---------------------------------------------------- // or just ? echo "<link rel='stylesheet' href='" . AIOM::CSS($myStyles) . "' />"; // or ? echo '<link rel="stylesheet" href="' . AIOM::CSS($myStyles) . '" />';

At least it let enough room for speculations. Did they have investigated? Is it a server config that they don't want tell about or change it? Or do they NOT have investigated and this is a boilerplate answer that is sent with enough timedelay? annoying!

If your fields are named " block_title" and " block_body", you need to call them with its names. In your example you are calling title and body. foreach($siteSettings->global_footer_blocks as $block) { echo "<div class=4u 12u(narrower)><section>"; echo "<header><h3>"; echo $block->block_title; echo "</h3></header>"; echo "<footer>" . $block->block_body . "</footer>"; echo "</section></div>"; } Does this work?

No, the module doesn't support it. And I cannot see much benefit for it. This is the only part what would be a really pain in the ***, if one would try to integrate this. And AFAIK, you get the same effect if you use the base64 data with your img src. And this can be done outside of the module. // when building your HTML-content, you simply can add something like $htmlcontent .= "<img src='data:image/png;base64," . base64_encode(file_get_contents($image->width(300)->filename)) . "' />";

Does using dedicated module files help a lazy programmer? For a private helper module I wanted to built, I decided to use the possibilities of dedicated files (implemented in PW 2.5.5) and not to write all into a single module file. Until now, I totally missed or forgot about this possibility. To my excuse: on introduction I may have thought not to use it early in my modules to keep backward compatibility. And then totally forgot about it. I allready use a tool for postprocessing in my sites. And I'm not familiar with all those popular node/grunt/gulp/npm/bower/and-what-else stuff out there. It looks to me a bit oversized for small to medium websites. But I also wanted not miss a comfortable, easy to use config for less and sass files, especially for those from frameworks like Bootstrap 3 / 4 or UIKit. So, what my toolbox should get added was a preprocessor (compiler) for sass (.scss) files first. I choosed the UIKit for the first shot. The created files for a configurable module called PreAndPostProcessor and a process module called ProcessPreProcessor were: PreAndPostProcessor.module PreAndPostProcessor.info.json PreAndPostProcessorConfig.php ProcessPreProcessor.module ProcessPreProcessor.info.json ProcessPreProcessor.css ProcessPreProcessor.js As you can read about the differences to the old-schooled style in Ryans blog post, I focus on what I found out to be most useful for me. Starting with the Config file, I decided to use the $this->add() method in the __constructor(). It is the way what needs less code to define your inputfields for a configpage: just a collection of arrays with field or fieldset definitions. Mandatory definitions are: type, name, label. Others are optional: description, notes, required, columnWidth, collapsed, showIf, ... And, of course, you need the definitions specific to your fieldtypes (value, options, ...). To group some fields into a fieldset, add a key called "children" to the fieldset array and add all field definitions to it as collection. Simple! Another nice thing I discovered, is the use of the *.info.json files. So, this I have used before, but not like here. The behave is like with the *Config.php files, - you write really less code, just arrays with key - value pairs and PW does the rest for you! Only difference here is, that you have to write it in JSON notation. The ProcessPreProcessor.info.json file contains the neccessary and common parts: title, version, requires. And some others: permission, permissions, page and nav. Page and nav are specific to Process modules. With page {name, parent, title} you define where PW should create you a page in the admin, and with nav, you can define a complete submenu for this page. For those who are yet not familiar with the internal structure of Processmodules: you can navigate to a submenu entry by calling it: {pw-admin-url}/{main-module-url}/{submenu-url}/. Calling the main menu url invokes the ___execute() method of the module. Calling a submenu url invoke the ___executeSubmenu() method. This all is really simple and straight forward. And it is really really helpful in cases like with the new toy for my toolbox. The nav is a collection of arrays, each holding at least an url and a label. Thats enough for PW to implement the menu and submenu for you in the admin. But you also may define an icon too. Aaaand, you also can add your own custom key / value pairs to it. PW does not complain on it. I have added a description. The nav was generated by parsing all core distribution scss files from the UIKit. They have a name and description in their first two lines. I programatically read this out and generated this nav notation for the info.json file: The (main) ___execute() method of the ProcessPreProcessor.module should present a submenu list with file infos. This now could be done by parsing the info.json file: public function ___execute() { // generate a navigation $dump = json_decode(file_get_contents(dirname(__FILE__) . '/' . basename(__FILE__, '.module') . '.info.json')); $nav = $dump->nav; $out = "\t\t\t<dl class='nav hnpp'>\n"; foreach($nav as $obj) { $out .= "\t\t\t\t<dt><a href='./{$obj->url}'>{$obj->label}</a> ></dt>\n"; $out .= "\t\t\t\t<dd>{$obj->description}</dd>\n"; } $out .= "\t\t\t</dl>\n"; return $out; } To make it even more friendly for lazy devs, , I created one method that is called from all sub-execute methods by simply passing their own name over into this function that loads and parse the scss file and displays its config page: The first version work out nicely. Here is a screenshot of it: ... and to answer the initial question: Yes, it does!

No, - no other / better ideas here. Just trying hard to follow up with most of the new stuff here (in the forums). Wondering how to best store / load / exchange them between different sites / installations. Textarea populated with json or simple json files?

@adrian: I have a question to the snippets collection. Are those snippets only meant to run in the Tracy console? (now powered with ACE!)

How long tooks it until it interrupts the connection? Does it also interrupt if you use the default PHP version of that server, this what is bundled as apache_module and not a one of the cgi versions?

The headlines ever have linked to the first post. To go to the exact post, you need to click the date / time links (those with the clock). This behave also is unchanged, it is like before! The only thing what have changed is that the circles and or stars are gone, what should bring us to the first unread post. But this only have moved. Now you personally can set this as your default behave. And with the new forum we can adjust a lot to our personal likes, what we couldn't do with the older one. I like it more and more. The embedded search is better now too. (Not that good than the google one, but better than the old one) I really appreciate @Petes hard work here. To me it looks like he is figthing a big thing. If you read the first announcement, he said that the forum would be down for 6 hours +, but later he changed this to an estimated downtime of only 30 minutes!, but with an uggly presentation for the first hours, as there have to run a massive background task to incorporate the old content into the new forums presentation. Alone this one is a massive support to the community. And if something wouldn't have went well, it would have been only up to him to fix this. He really trusts into the coumminty to do well with (not editing) the old contents during this period. (To be honest, I wouldn't have done so. I would have totally closed it for 12 hours. ) So, a big thanks @Pete!

sorry, but the most things are where they were before, at least it is how it looks to me. what taskbar are you talking about? can you please post a screenshot?

Don't know how often the data will change, but it would be a possible solution to cache your template markup and rebuild it on storing new data. This would ommit the code execution everytime, without the first request after new data was stored.

Hhhm, yes! For me it is it a bit too. But I thought to try it out and maybe it is lesser code to write. We will see how it goes.

Ah, great. I figured it out myself! We need to add all fields into a children array: $this->add( array( array( 'type' => 'Fieldset', 'name' => '_myfieldset', 'label' => 'Fieldset Label', 'collapsed' => Inputfield::collapsedYes, // Inputfield::collapsedNo 'children' => array( array( 'type' => 'select', 'name' => 'kit_type', 'label' => 'Select the Kit you are using', 'options' => array('uikit' => 'uikit'), 'required' => true, 'columnWidth' => 50, ), array( 'type' => 'text', 'name' => 'kit_fullpath', 'label' => 'directory site path to your kits scss sources', 'columnWidth' => 50, ) ), // close children ), // close fieldset //.. add more fields ));

As the subject says. With the ModuleConfig, we can define our fields in the MyModuleConfig.php __construct() method with calling $this->add() and pass it an array with lots of field-definition arrays. This is working fine with fields on one level. But how can I organize them into fieldsets? I have tried a bit with multidim arrays, but no luck. Has anyone does this before? Is anyone using this "new" config method? (implemented in PW 2.5.5)

Hhm, looks like the OPCache class is not ready to use with PW3 namespaces. Unfortunately I have no PW3 installl with OPCache installed where I can test it. To the first error, I can say this sounds a bit weird, because I try to get the Page of Admin -> Setup (what is 22) and than checks if it has a children Page with the name of the OP-Cache Viewer. So this should return A) the page if existing, or B) a NullPage object. Both possible returns are objects. So, without able to test, it looks weird. What ID does your Admin Setup Page have? --- I suggest to uninstall the OPCache Viewer and only use the Admin Links In Frontend module until I got solved this. (What may take a while, )

Not hundred percent sure, but maybe you can make use of the AdminCustomFiles module. Besides others, it lets you create an AdminThemeDefault.css and an AdminThemeReno.css file under site/templates/AdminCustomFiles/. There you can write all your custom css in regard to each theme. In regard how to determine which language is active, I must admit that I don't know this. This is left over for others to answer, sorry. --- And welcome to the forums, you PW-veteran.

Many thanks @netcarver. I must admit that I have written the Textfile-driver only for this module to have a basic driver. Other as the SQLite-driver, it has not have much testing. I'm glad to hear that you have done this and you contribute to the module. I have you added as colaborator to it, so that you can change / add other improvements / enhancements as you like.

If you have to select a lot of images out of a mass, it is of real help, if the images are presented in a way that does not visually show one sort more prominent. It was by no means design what I have talked about. It was definetly about "to get the job done as fast as possible", what can be done way faster if a redacteur does not have to abstract those massive differend presented formats when comparing images against each other. Believe me, also if Pros in that field are able to abstract that a lot faster and better than None-Pros, - after screening 1k or 2k images, they would kiss every one who brings them a more weightened images table for their work.

From a photographers or images redacteurs perspective I would say that the best presentation option would be a weightened one, based upon amount of pixels! see in the comparision image the first and second set of images: https://processwire.com/talk/topic/8367-pia-pageimage-assistant/#entry81648 This way, neither landscape- nor portrait- oriented images, nor square dimensioned ones become visually more present than the others.

Maybe you can keep it in the session only? When opening a page with the filefield, getItems() into a session var. After saving the page, compare it to the new getItems() values. You may even finegrain this a bit more: track changes of the filefield and only if there were changes, compare it with the new values.

I can confirm this. This persist since a long time back in the past. Since then, we only upload bunches of images packed as zip archive. But until now, I wasn't aware that it may have to do with the SessionHandlerDB.

When working with Namespaces, (PW3), it is allowed to use different namespaces in one file. Assuming you have a php file you want to include with this code: <?php echo "<p>I love $var!</p>"; you can have a template file like this: <?php namespace ProcessWire { // ... } namespace fake1 { $var = 'apples'; include('./_namespace-include-test.php'); } namespace fake2 { $var = 'bananas'; include('./_namespace-include-test.php'); } namespace ProcessWire { $var = 'oranges'; include('./_namespace-include-test.php'); // ... } The output will be: Why and how this works is in the PHP manual. There you also can read that this is bad practice.

Maybe a bit OT, but: If you add files to a page, you use a filefield (or imagefield). You haven't told what you want to do, but maybe you also can use other hooks? https://github.com/ryancramerdesign/ProcessWire/blob/devns/wire/modules/Inputfield/InputfieldFile/InputfieldFile.module#L457 https://github.com/ryancramerdesign/ProcessWire/blob/devns/wire/modules/Inputfield/InputfieldFile/InputfieldFile.module#L491 ... and welcome to the forums!

You don't need anything like this. Just make sure that your php files are really stored in utf-8 encoding!! (PHP files you need to check in this reagrd are: the calling template file(s), the WireMailSMTP module files and the base WireMail files) Normally they all should be in utf-8 encoding, but better you check this thouroughly. Then it works with simply using: $subject = 'Ö Ä Ü ö ä ü ß'; I tested this just yet. The source of the received email looks like: Subject: Wiremail-SMTP Test 15:57:23 =?UTF-8?q?=C3=A4=C3=B6=C3=BC_=C3=84=C3=96=C3=9C_=C3=9F?= X-Mailer: ProcessWire/WireMailSmtp Date: Wed, 8 Jun 2016 13:57:25 GMT +00:00 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable It does automated encoding, but you don't have to do anything by yourself.