Pixrael

Yeah, I Know.. but with PW you can do whatever you want!! lol

hehe, like this

Ok, perfect! Thanks

Hi kongondo, one question: the title of the page is always taken from the module? Because after creating the menu, I modified some page titles in pw by request of the client and the module continues printing the old title. Maybe I can use a var %s or something in the title input to tell the module that get it from the pw page.

The new <pw-region> works like a charm !! .. thanks so much Ryan! I'm so happy !! ..This addition saves tons of time/code per year for me. If the FileCompilerTags could work fine, I would have my full-set of front-end tools ready .. fantastic Saturday for me

I agree with you, I was just trying to think of a way to freely act over the elements. Sorry for this crazy post ;-)

The recent introduction of the Markup Regions has caused some excitement in our community, mainly for the simplicity of the proposal to output our markup, but for the various opinions about how to select and modify the regions, maybe it should not be the definitive solution. Perhaps the most correct option is to think this output strategy in the "Processwire style". Something open and versatile. The solution could be: Have the layouts files (main.php) as our "Markup Database" and then with the templates files (home.php) we can do "CRUD operations" on it before the output, using for that a jquery/processwire like API. This could be a powerful way like the current excellent API solution to manipulate the data. Where $markup come from the layout file "_main.php", in our templates files we'll can do: <?php $markup->find('#sidebar').prepend(' ?> <div class="foobarcontainer"> <h3>Hello <?php echo $page->foo ?></h3> <p><?php echo $page->bar ?></p> </div> <?php '); ?> <?php if ($hidecomments) $markup->find('.comment').addclass('close'); ?> <?php $markup->find('#sidebar .contact ul').remove(); ?> Etc. Think about the possibilities, it will no longer be necessary to define regions, the regions are any part of the document It's just an idea, maybe is a really hard to-do solution, but will be perfect for the Processwire ecosystem as the direct-delayed output workflow. In GitHub already are several php libraries for select DOM elements using any css selector in a jquery like style.

I do not mention it but part of my idea is because I use a lot of the code completion of my IDE, it makes me work faster and with less errors, so I hate the concatenation of variables when I write a mix of html tags with php Code .. yes I'm lazy but I love it

Thanks for your comments, I also reviewed how Ryan implemented it, from there come my idea. I currently use a Latte Engine Module, but for 90% of the web pages my clients need is too much of the view/controller model, it's a lot of work for simple things. That's why I like what Ryan did, but I need regions that be more versatile in defining where to place it in the document, that not use the classes/ids directly and be less complicated in terms of the number of directives and tags variants. Just do it simple. An illustration example: https://processwire.com/talk/topic/15582-markup-regionsidea-for-another-placement-attribute/

Continuing with the idea, to include some functionality of the current implementation: Having in _main.php <!---[pw foo]--> <p>Lorem ipsum dolor sit amet</p> <!---[/pw]--> in template files to replace <!---[pw foo]--> <h2>Curabitur nec odio et elit iaculis posuere. Aenean finibus felis justo, vel porttitor tortor malesuada et.</h2> <!---[/pw]--> Output <h2>Curabitur nec odio et elit iaculis posuere. Aenean finibus felis justo, vel porttitor tortor malesuada et.</h2> in template files to prepend <!---[pw +foo]--> <h1>consectetur adipiscing elit</h1> <!---[/pw]--> Output <h1>consectetur adipiscing elit</h1> <p>Lorem ipsum dolor sit amet</p> in template files to append <!---[pw foo+]--> <ul> <li>Proin iaculis feugiat tortor</li> <li>Vestibulum vestibulum ultricies semper</li> </ul> <!---[/pw]--> Output <p>Lorem ipsum dolor sit amet</p> <ul> <li>Proin iaculis feugiat tortor</li> <li>Vestibulum vestibulum ultricies semper</li> </ul> in template files to inherit <!---[pw foo]--> <h1>consectetur adipiscing elit</h1> <!---[pw ++]--> <ul> <li>Proin iaculis feugiat tortor</li> <li>Vestibulum vestibulum ultricies semper</li> </ul> <!---[/pw]--> Ouput <h1>consectetur adipiscing elit</h1> <p>Lorem ipsum dolor sit amet</p> <ul> <li>Proin iaculis feugiat tortor</li> <li>Vestibulum vestibulum ultricies semper</li> </ul> in template files to remove <!---[pw foo]--> <!---[/pw]--> And finally if the region is not declared in the template file, output the initial content.

I do not see the problem of using comments, especially during production. I usually use comments to identify parts of my code in the nesting nature of the DOM tree, in a format similar to: <! -- here start the header - -> <! -- end of the header - -> I only propose a nomenclature to be able to easily identify the regions using a parsing code. Not in conflict with other comments used in the code.

As a graphic designer I like the new options to output markup with the templates (region function and regions markup strategy) but testing them I think they could adapt a little more for ease of use. In this proposal I modify the syntax and the way of assigning the values, while I try to maintain the concept. Next the common example, in "_main.php" <!doctype html> <html class="no-js" lang=""> <head> <meta charset="utf-8"> <meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1"> <title></title> <meta name="description" content=""> <meta name="viewport" content="width=device-width, initial-scale=1"> <!--[pw headseo]--> <!--[/pw]--> <!--[pw headstyles]--> <link rel="stylesheet" href="css/normalize.min.css"> <link rel="stylesheet" href="css/main.css"> <!--[/pw]--> <script src="js/vendor/modernizr-2.8.3.min.js"></script> <!--[pw headscripts]--> <!--[/pw]--> </head> <body> <!--[pw header]--> <h1><?php echo $page->title(); ?></h1> <!--[/pw]--> <!--[pw body]--> <?php echo $page->body(); ?> <!--[/pw]--> <!--[pw footer]--> <!--[/pw]--> <!--[pw footerscripts]--> <script src="js/jquery.min.js"></script> <!--[/pw]--> </body> </html> then in the template file "home.php" <!--[pw headstyles+]--> <link rel="stylesheet" href="css/home.css"> <style> body { padding-top: 50px; padding-bottom: 20px; } </style> <!--[/pw]--> <!--[pw head+]--> <h2><?php echo $page->headline(); ?></h2> <!--[/pw]--> <!--[pw footer]--> <h3>About Homepage</h3> <p>Lorem ipsum dolor sit amet, consectetur adipiscing elit. Donec efficitur dignissim nisi nec consequat.</p> <!--[/pw]--> Well I'm not a programmer, I hope you understand the above. But the idea is: Using html comments for regions definition, this is a standard in html, and not interfere with the DOM or with the page structure, allowing using it in document areas that are not visual. The current option basically is to use DIV but this is not correct in areas like the head tag. Using the open/close tag system allow the use of IDE features for html as auto-completion, code coloring, code validation, visual previews and more. Allowing populate the initial values for regions without variables concatenation and with the previous advantage (auto-completion, code coloring, etc) The pages can be render without additional Ids and class, maybe useful for debugging and can be cleaned in production with something like $config->cleanRegions = true; It can support the current prepend, append, before, after etc regions strategy, I think its a mix of the current Region Markup. As I said I am not programmer but I think it can be implemented using Output Buffering ob_start (); ob_end_clean (); capturing the code between open/close comments tag and assigning them to the corresponding region ... If someone likes and have time to analyze and improve this idea, are welcome because I don't know how to implementing it .. sorry

I agree with you, in my sketch I adjust the margins and eliminate lines to make it more compact and clean... more contrast can help too

The following comment really belongs to this topic, was my mistake :-( https://processwire.com/talk/topic/15593-new-blog-post-continuing-work-on-new-admin-theme-framework/?do=findComment&comment=140139

I like it, this new version of the admin theme is a step forward for Processwire. I'm a space fan in the design, I like when the user interface can breathe a lot, but I think it's too white or too "light" now, it's hard to see on a 27-inch monitor. I would like the color of the header bar, buttons hover and other small details can be configured in the administration, as well as the logo (keeping the height) to match the brand of our customer, this will be a great advantage. Of course the Processwire identity is maintained in the footer. I think the default color may match the Processwire website that I like and it's refreshing. The developer can customize with parameters in the administration, this can be achieved using a small css file with color codes to override some elements and this file can be generated when the profile page is modified. I was modifying some screens directly with the Chrome Inspector and this is the result. I made adjustments in the background tones, margins, colors, hiding elements like lines, etc. For example, the help paragraph that is always visible, it would be nice to display it on demand with help icon or directly by activating them in the VIEW menu. Because it is useful the first few times you use Processwire, but when you learn it only occupies an unnecessary space.

https://github.com/mauricius/TemplateEngineBlade

I have also experienced this slowness for a while. Solving this issue should be at the top of the Roadmap for 2017 because of the effect it has on the SERPs and the User Experience. I think it's more important than new features or the expansion of existing ones. Today Processwire is so powerful and versatile, now should make a stop and solve this delicate problem before continuing to advance. What do you think guys ? Ryan?

About the API variables: It seems perfect because in any medium projects you need almost all those variables, then from factory you have all the infrastructure ready to work. If you need something from the PW API it's there, it's much better for newbies. If you are a fan of optimizations (you are supposed to be a smart programmer) you can go to the module source and remove it, or whatever you want to do with it.

For site review you can use https://gtmetrix.com/ .. It looks like the site needs some fixes for better performance

Read this for some insight https://processwire.com/talk/topic/12969-intermediate-template-structure-without-string-concatenation/

OK, so easy as usual in PW!! Thanks Note: Maybe this question is out of the scope for this entries, so if you want to move it to another topic is okay.

So, if I need to use the "init", "ready" or "finished" files in my project, I put them in the site root. But, I need to configure PW to include them in the process?

I have some PW installations with the "ready.php" file in the site root and others not, Why? For example "Default" profile have it, but "Multi-language" not. It's best practice using it?

Great! BitPoet thank you very much, for your time and your effort, this is an incredible community! I'm so glad I found this place. I'm a graphic designer with a lot experience making Web/UI/UX designs, but always associated with programmers who build the business and data access layer, I just make the design and layout with html, css and some javascript, mainly jquery. But finding Processwire and see the ease of use, at least for small business marketing sites, gave me the courage to make complete projects for myself, and although I fully understand the whole concept of working with Processwire, in these initial steps I stuck a little on small details and decision making in which is the best way to go, for example: using some templates system or not, etc. But I'm motivated to continue (sorry for my programmers hehe) now I'm starting to prepare an starting site profile with everything prepared for this kind of webs, that help me to start new projects quickly from it.. bye wp! So again thank you very much for your help and everyone here.

Yes, I test that site profile before, but I decided to build my site from scratch with the blank profile and using a template system. I try to reuse the language switcher found in that profile. but it makes use of functions (localHttpUrl, localUrl) that (I think) are only available when you install the LanguageSupportPageNames module, and will not really use it. I already install the base Language Support module and the Language Support Fields module. I understood that the use of Language Support Page Names module was optional to support multiple languages :-( It's simple, I only need the current page url for each language available