Leaderboard

I would prefer cookies instead of sessions for such user-choices. Sessions expire when you close your browser, but cookies will still be remembered after x days (= the lifespan you define). You can set cookies with JS alone, so you don't even need a server / PHP for that.

I build and use one template that is bound to a single page in PW where both are simply named "ajax". I can access it per URL "/ajax/" and use it for everything that needs to send or retrieve data in the background. Here is an example from a project where different forms send data that need to be validated first and then send to final (external) destinations. The client browser optionally gets back HTML like "success messages" or error descriptions. <?php namespace ProcessWire; /*============================================================================== XXXXXXXXXX :: site/templates/ajax.php 2019-07-04 ==============================================================================*/ /******************************************************************************* * * This template file handles form submissions that are raised via AJAX! * * Sanitize, validate, log and submit to final destinations. * * // how the used JS looks like $.ajax({ url : gAjaxUrl, // /ajax/ type : 'POST', async : true, dataType : 'html', // returned data has to be HTML data : submitData, // submitted data object success : function(markup) { if('' != selector) { // a selector string to match the $(selector).html(markup); // markup container } } }); ... * *******************************************************************************/ // only process AJAX calls if(!$config->ajax) return 'WRONG ACCESS METHOD'; // only process POST requests with valid required id if(!$input->post->hidden_id) return 'WRONG ACCESS METHOD'; // ... followed by all project specific validations etc. So, with your example I would check if there is a post value named theme, and if the value is one out of a whitelist of valid theme values: // does this belong to theme selection if($input->post->theme) { $validThemeValues = ['dark', 'light']; if(!in_array($input->post->text('theme'), $validThemeValues)) { header('HTTP/1.1 403 Forbidden'); return; } $session->set('selectedTheme', $input->post->text('theme')); return; } // does this belong to another thing? if($input->post->anotherThing) { // first validate, then process data // ... return; }

Thanks Bernhard! I might've indeed read your post somewhat wrong. Now that I've re-read it along with your comments (and watched the video), I think I have a better idea of what RockThemes is all about. I can even see some similarities with wireframe, although I'd still argue that they are few, and they seem to mostly apply to the view layer – or a part of it ? The word "theme" might've thrown me a bit off, yet now that I'm reading your post for the third time or so, I'm still not sure what else to call it. Correct me if I'm wrong, but technically you're talking about having the template files (/site/templates/*.php) populate a content variable, and the theme pretty much defines what "wraps" that site-specific content? Still not entirely sure I got this right, so I may be completely on the wrong tracks ? By the way: as a bit of a disclaimer please don't take anything I say here as disencouragement. That is not my intention. I think your idea has plenty of merit, and it's thrilling to see projects like RockThemes that, in some ways, challenge the status quo. Trust me, I've been there. Your concern is perfectly valid and familiar. Site profiles are intended as starting points, and they don't scale beyond that ? One solution to your problem from my point of view: if you have a feature that you want to use on multiple sites either as-is (or perhaps with some modifiable settings), bundle it into a module. Menu generation, metadata output, favicon generation... this sounds like three separate modules to me. Or one module that does it all if that makes more sense, but at least in my experience separate modules tend to make more sense as they provide more flexibility. If it's all bundled into one package, you tend to run into problems if you want to modify your metadata generation method – but the modification only applies to, say, five out of those ten sites. Not to mention the two that require an entirely different solution, etc. The point is that in my experience it's better not to bundle too many assumptions into one package. "One module, one concern" ? (A bit off-topic, but the "small modules" approach can sometimes result in a more work when it comes to updates. That, in turn, can be resolved by using a module manager, or – my personal preference – Composer. Or, alternatively, Git submodules.) Even after re-reading your post, I still think that the purposes are somewhat different. Let me elaborate on that a bit... ? For me one key point about wireframe is the separation of the business logic ("code", which is implemented as the methods of the Controller classes) from the presentation layer (the "dumb" views, partials, and layouts). The amount of markup generation features in wireframe is also exactly zero: it provides structure and "connects the dots" between different components, but the rest of the implementation is entirely up to the site in question. One example (I'm trying hard not to go too deep into my own "vision" here) are the sites I've built with the predecessor of wireframe that didn't have a "human-readable" UI. API first (or "headless") sites, that is. I've also built sites that didn't even have an API – only code that was triggered behind the scenes by scheduled scripts – though admittedly that's a rare use case. In wireframe controllers and various view components are all optional, which means that there may be sites that use them all, as well as sites with just a backend or just a front-end – not to mention that a site with a front-end may still use just a part of the view layer: all templates could use a single layout file for rendering, but they might as well not use a layout file at all and instead rely on template-specific view files for all their rendering needs ? Right – this makes sense, I think. I don't think I've yet seen in your examples how one would extend a theme, but I'm assuming that the general concept is that you've got one theme that you copy from project to project, and then for each project that differs from the base theme in any way you create another, site-specific theme that you customise? If that's correct, this reminds me of WordPress' themes and child themes. In that context the idea is that you can update the parent theme and your site will stay intact because all the modifications are in the child theme. (This, of course, doesn't always work because the child theme may override something that changes / breaks when the parent theme is updated, new version of the parent theme may add or change a feature that the site relies on / doesn't need, etc.) On the other hand RockThemes itself is more like a "theme frameworks" in that it provides the base implementation for themes to build on, and possibly a number of general purpose helper features, components / blocks (?), etc. Hard to say what those would actually be without seeing the module, so I could be on the wrong tracks again, of course. I'll have to give this a few more moments to really sink in, after which I might have more questions / suggestions. Anyway, If I'm following you correctly, I like what you're doing here but wouldn't personally go this way – partly because I'm already invested in wireframe (obviously), but also because this doesn't seem to solve the issues I mostly struggle with (such as the part about separation of concerns). The issues with updating stuff, on the other hand, I've managed to resolve via other means, so for me that's mostly a non-issue ?

What about a scenario when client upload a webp image (.webp renamed to .jpg)? I just had that case with one of my clients on pw 3.0.123. With processwire 3.0.123 I am able to edit and view the page with uploaded webp image. Only drawback: no thumbnails are generated. Now, reproducing that scenario with pw 3.0.141, whenever I try to edit or view a page containing uploaded webp image, I'm getting 500 internal server error. Tracy says: ProcessWire\WireException webmimage-9.0x260.jpg - not a supported image type Source file: File: .../dev/wire/core/ImageSizerEngine.php:574 574: throw new WireException(basename($filename) . " - not a supported image type"); Its the same error with either GD (2.1.0 compatible) or ImageMagic (6.9.4-10 Q16 x86_64 2017-05-23). PHP version: 7.2.22 ------ @Ivan Gretsky, I was able to convert your image to webp with GD and ImageMagic (libraries, php and pw version same as above). (blue background is from a css style)

Hi Teppo, thx a lot for your thoughts ? Almost ? Technically it's 2 parts: 1) The module (framework) that lives in /site/modules and provides helper functions (just like the pw admin), eg $theme->assets->render() that could render all js scripts and css styles in the head (that can be populated easily in all your templates via $theme->assets->add("assets/main.css"); $theme->assets->add("assets/main.js"); 2) The theme files that live in /site/templates/yourtheme and provide all the markup generation blocks (the basic setup is very similar to the default site profile). These files can easily be pulled from github. 3) Optional: Theme customizations, eg /site/templates/mythemechanges that only provide those files that are different from the master theme (eg a custom logo). Technically building themes is even possible at infinite recursion levels (themeMaster, themeChild1, themeChild2, themeChildN) where the first existing file is taken, starting from themeChildN (whenever it is requested as $theme->getFile("blocks/foo.php"); It's not about populating a $content variable in the theme files. It's more about providing the presentation layer (views) that can be shared across projects. The logic still has to be built into every single project, but with the huge difference that it will be as simple as that most of the time: <region pw-replace="header"> <?= $theme->render("blocks/menu.php") ?> </region> In the example above I'm just using the $content variable of the default site profile, but that just shows how flexible this approach is and that's by no means a necessity! ? In other words: In the example above I'm using the business logic of the default site profile just by including _func.php and the current template file and I'm using 2 presentation layers, first the default uikit theme (the bright one) and then the second theme with the default and secondary uikit colors. Trust me, I've been there ? ? And I disagree (but also not meant in a bad way). ProcessWire gives us the freedom to build things the way we want and that's what we all love it for, don't we? ? The problem that I see with those markup generation modules is that they are either opinionated about the output (only support one framework) or don't look good or are just not easy to use. I'm building all my sites with uikit, so it's tedious to create a menu like this: $options = [ 'active-class' => 'uk-active', 'child-item-template' => '<li {class}>{title}</li>', ... ]; $modules->get('WhatSoEver')->render($options); Why? Because I'm not clever enough to always remember the correct markup/syntax and the module has other defaults (because the module author might not use uikit) and I'm doing this waste of time (and fun) over and over again... Actually I've not done too much frontend stuff, but I try to avoid repeating work as much as possible ? But you got a valid point here and I'll think about that more closely (what should be part of themes and what should be a separate module). Well, that's a good thing as it means that we are not building the same thing twice ? But I'm still not sure about it. See the explanation about the $content variable above. Isn't that separation of concerns in the way you mean it? It would also be easy to provide a similar feature to RockThemes that calls a Controller file before it renders the template/block (or view, if you want to call it like that). Eg you could have the template file /site/templates/yourtheme/blocks/header.php <region pw-replace="header"> <div uk-grid> <div><?= $logo ?></div> <div><?= $menu ?></div> </div> </region> And then you could have a controller file /site/templates/yourtheme/blocks/headerController.php: <?php namespace ProcessWire; class headerController extends themeController { public function renderMenu() { return '<ul><li>...</li></ul>'; } public function renderLogo() { return '<a href="..."><img src="..."></a>'; } } I think I like that concept... But I have to think about it ? Same with RockThemes ? Yes, that sounds like finally we are talking the same language ? Extending themes could either be done just by replacing a content block (by just placing a file with the same name in your child theme) or - don't forget about we are still using ProcessWire ? - hooks! <?php $theme->addHookAfter("render(blocks/footer.php)", function($event) { $event->return .= "<div class='uk-text-center'>Hello World added by Hook</div>"; }); Or something like this: <?php $theme->addHook("HeaderController::renderFoo", function($event) { $event->return = 'BAR!'; }); Would be great to hear what you think about all that, thx! ? Have a great week everybody! PS: Another story that would make a lot of sense once we have some kind of standard in the frontend just like we have in the backend ($config->scripts->add(...)) would be some kind of site builder features. I've talked about that with @Jonathan Lahijani as he has put huge effort on that topic during the last year.

Hey folks, @kongondo asked me some questions about how I integrated vue.js into ModulesManager2. I was already planning to release a tutorial video of the integration process soon, but I don't have much time now as I am busy with customer work. So here is a quick roundup, which will be improved over time and become a full-blown tutorial. I hope to cover the basics and don't forget anything. How did you implement the integration? I created a new vue project via vue create . inside my site/modules/mymodule folder Do your assets still live under the Vue JS public folder? I don't exactly know what you mean with assets. Are you speaking of images? I don't use images atm. Where do your view files live, i.e. under your modules directory or in templates? As I mentioned in point one, they are in the modules directory. Here is a screenshot of my directory: As soon as I release the beta of ModulesManager2 you can go through the source code in github. Where is your index.xxx file and how are you serving it? vue-cli comes with a built in server and the index.html is automatically generated on-the-fly. The command for running the server with HMR (hot media reload) resides in the package.json and is run via npm run serve This is the standalone server. Anything else I should know (maybe .htaccess issues, etc)? Create a vue.config.js in your custom module's root directory and add following parameters to it, to disable filename hashing: const webpack = require("webpack"); module.exports = { runtimeCompiler: false, filenameHashing: false, pages: { main: { // entry for the page entry: 'src/main.js', // the source template template: 'public/index.html', // output as dist/index.html filename: 'index.html', // when using title option, // template title tag needs to be <title><%= htmlWebpackPlugin.options.title %></title> title: 'Index Page', } }, configureWebpack: { plugins: [ new webpack.ProvidePlugin({ $: 'jquery', jQuery: 'jquery', 'window.jQuery': 'jquery', }) ] } }; Edit: After creating the config run npm run build Then you can reference these files in your module like I did here: $markup = '<div id="app"></div>'; $scriptPath = $this->config->urls->siteModules . $this->className; $markup .= "<script src='$scriptPath/dist/js/chunk-vendors.js'></script>"; $markup .= "<script src='$scriptPath/dist/js/main.js'></script>"; I added the configureWebpack part to have access to the $ and jQuery objects inside of my vue files. The install/uninstall overlay panel in MM2, is that something custom or a ProcessWire panel? Standard ProcessWire panels If it is a ProcessWire panel, did you have any difficulties implementing it into your Vue app? ProcessWire's panel init happens before vue is initiated or rendered, so pw-panel links inside of vue are not catched. To make pw-panel links inside of vue work, you have to defer (don't know if this is the correct term) the process to a body click event: $(document).on("click", "#app .pw-panel", function (e, el) { e.preventDefault(); let toggler = $(this); pwPanels.addPanel(toggler); toggler.click(); }); I hope this helps. If you have questions, please ask.

Put this code inside your ready.php which you will find inside your site/templates/ folder. If there is no such a file then create one (site/templates/ready.php)

@MFox, you need to install PWImage ckeditor plugin, enable it and add it to your toolbar (see screenshot).

@tires Thanks! The meta tags need to be HTML encoded because they are rendered inside HTML tags. This is not an issue, the tags will appear correctly in Google. The "&auml;" you are seeing in the source code is not related to the character encoding, it is just a character being HTML encoded. Cheers

Cool. Just an FYI in case you aren't aware... modules can create and remove admin pages on install / uninstall, which is where that ajax url would live.

@apeisa @Soma Just noticed that the modules directory entry for this module still points to the old repository, and also doesn't list Multisite as being PW3.x compatible. Would it make sense to update the entry to point to Soma's repository? We just did a similar shift for AdminBar, and Adrian made the necessary changes in the modules repo. Also, I'm currently not entirely sure which branch I should use – last I checked it seemed that "dev" was the one to use, but since then that has apparently been removed (or renamed) and now there are two branches left: master and dev2. Master is the one with most recent updates, so is that preferred over dev2, or vice versa? Sorry for all the silly questions ?

Is there any chance to get stars and voting for comments in Uikit 3 “Regular” site/blog profile soon? Any working solution would be great.