horst

Thats what I was talking (thinking) about when agreed to @tpr and @szabesz : the use of the UA-Switcher. Honestly I think, when already using (installed) TracyDebugger, there is no need to have an additional UA-Switcher elsewhere. But I'm using ALIF everytime. In my local (not yet released) version, ALIF even has a toggle button to switch on/off the TracyDebugger And I use it in production sites for frontend edit- and logout- buttons for editors. That was the initial reason why I have written it.

@Robin S 's solutions are perfect. My personal favourite would be the first one: just working with the basic page tree and hidden / unhidden or published / unpublished states. If you want go with another pagefield solution (checkbox), but want to have a good visual sign rendered in the page tree, there are some code examples in the forums here how to use a hook for that. Other than in the linked example, with recent PW versions, you don't need a module for that. You just can add a code snippet for that hook into your sites init.php. If you need any further help, just ask.

That's correct! This is one more example on how things grow in our community: we work together to make it as good as we can. Someone come up with a good solution for a partial thing. This a) directly help others, it b) inspires other users to new / other solutions, and this, in the end, makes working with our beloved PW a little more better again. And, in this case, (ALIF and Tracy): from now on, everytime when I will use Tracy, I will have the feeling that a little part of my work is into it.

What I cannot understand is how the file sites.php in the root folder could stored, the index.php gets an injected line, because those are not under sites/assets/. I assume that you haven't had set 777 for the webroot. So, how can this be possible?

I think you need explicitly set: Options Indexes to allow it, and not to disable it. But it also can be that on this (shared?) host, you have no rights to change this. Just try if it work or contact the hosting support if they can enable it.

I think that you: a) have only used short syntax for echo(ing) strings: <?= what is not the same as the short php opener. Please check and confirm. b) now, it is parsed and tells you that you have a parse error. A parse error at the last line of a file occures when you somewhere have an unclosed level of, e.g. foreach, if statement or something else. You have to go through your code and check if you have closed each opened one. In tis regard, I want to say that the code you use is not the best solution. I personally find it really hard to read, and it also is hard to maintain. There are many ways to keep the logic aways from the markup. Big and small solutions. But everything seems to be better than that. For example, you can do the php logic in the top of the file, and than merge it together with the markup. <?php // open the file in PHP mode, /** add comments to the file if needed. * This is a good place here. :) **/ // define a markup template with placeholders $myMarkupTemplate = " <a href='#'> <div class='port'> <img class='pic' src='[_URL_]'/> <div class='portbgrdtext'> <h5>[__GENRE__]</h5> <p>[__TEXT__]</p> <button class='portbtn'>Read More</button> </div> </div> </a> "; // now get your page and loop through your selections $portfolio = $pages->get("name=portfolio"); foreach($portfolio->portfoliopreviews as $portfoliopreview) { $search = array('[_URL_]', '[__GENRE__]', '[__TEXT__]'); $replace = array($portfoliopreview->portimg->url, $portfoliopreview->portgenre, $portfoliopreview->porttext); echo str_replace($search, $replace, $myMarkupTemplate); } Another approach could be <?php // get your page and loop through your selections $portfolio = $pages->get("name=portfolio"); foreach($portfolio->portfoliopreviews as $portfoliopreview) { $url = $portfoliopreview->portimg->url; $genre = $portfoliopreview->portgenre; $text = $portfoliopreview->porttext; echo " <a href='#'> <div class='port'> <img class='pic' src='{$url}'/> <div class='portbgrdtext'> <h5>{$genre}</h5> <p>{$text}</p> <button class='portbtn'>Read More</button> </div> </div> </a>\n"; } or you ommit the temporary variables and put out the field values directly: <?php // get your page and loop through your selections $portfolio = $pages->get("name=portfolio"); foreach($portfolio->portfoliopreviews as $portfoliopreview) { echo " <a href='#'> <div class='port'> <img class='pic' src='{$portfoliopreview->portimg->url}'/> <div class='portbgrdtext'> <h5>{$portfoliopreview->portgenre}</h5> <p>{$portfoliopreview->porttext}</p> <button class='portbtn'>Read More</button> </div> </div> </a>\n"; } There are many ways one can go.

The php server environment where you use this code, has short php syntax disabled. To be save and transportable with your code, you never should use this. Always use <?php to enter into php mode. Better don't use <?

any restrictions in the network or server your work computer is located?

Haven't used it now, but already like it! (have had a look to the readme!) Below an example of a root parent and a first level child:

Regarding a cropped version: Is it right that we easily can create a new cropped-out image (variation) with the individual cropping tool of the core imagefield, and then, in a second step, select this new one an define the focus point? If this would be possible, I think then there is nothing left out.

It is an interesting option. Only thing that I may think of what is not good, is that it ever takes full width or full height of the original image. There are use cases where one want crop out a part. But for many other cases this seems a good solution. If I understand the concept right, there would be less hassle with lots of variations. Right?

Yes, please only use the second one. Best is to uninstall the first one. The first one is obsolete, as it only supports the older image variations naming convention, and not the new one, introduced in PW 2.5.11.

simply go to the modules directory, you find it directly on the first page under "User Favorites", the second item. Or here. Your other questions I don't understand. ?? In the modules package are a module pim1 and a module pim2. If you use a PW version greater than 2.5.11, please do not install pim1, install pim2! That's all. Hope this helps?

Hi @kixe, first just want to say thanks for this useful module (if I don't have already)! And I want to share a usage that propably wasn't intended with your module, but I find it useful for small sites where content changes slightly in a weekly manner or less. I use a hook into Session::logout in the ready.php file that invokes a DB-Backup. Currently the simplyfied code looks like: /* Autobackups */ $wire->addHookBefore("Session::logout", function(HookEvent $event) { if(!wire('user')->hasPermission('db-backup')) return; if(wire('modules')->isInstalled('CronjobDatabaseBackup')) { // execute a cronBackup ignore_user_abort(true); set_time_limit(120); $cdb = wire('modules')->get('CronjobDatabaseBackup'); $e = new HookEvent(); $cdb->cronBackup($e); } return; }); This is a bit hacky. What do you think about to embedd a public method to do this more transparent. Also it would be good if the description ($fileinfo) could be set dynamically with this method or as separate method or option. Currently I have hacked this into the module to be able to set it like: "logout horst (CronjobDatabaseBackup)". Anyway, also without that, it is a big, big helper!

I believe he meant what he has said: " Keep in mind that include=all will include a lot more than just unpublished pages." If it currently is working for you with include=all instead of include=hidden as suggested by @LostKobrakai, you only need to wait until the first page in your trash will match the selector too.

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!