szabesz

This one? Looks nice to me If you were to write a separate tutorial as the development unfolds that would be cool.

Thanks for the info @adrian! More thumbs-ups for valieand's request please: https://github.com/processwire/processwire-requests/issues/23 @ryan says: "Please note that we generally avoid adding features that aren't going to be used by at least 30% of the ProcessWire audience." Let's reach that 30% or even more!

It is at least possible to use the forum to learn from others, but not practical and rather hard to do it on IRC. Forum content is searchable and somewhat organized, while IRC is not. The latter is good for what you normally use it for. Forum is a usable replacement for in-depth docs and/or books. I think this is what he meant. If so, I agree

Hi, Something like this? More links to solutions: By Soma explained as an admin example: http://soma.urlich.ch/posts/custom-js-in-processwire-admin/ but works on frontend too, as long es we output in the head for dynamic variables https://processwire.com/talk/topic/8343-access-page-and-pages-variables-from-inside-a-javascript-file/#entry80823

I see. Then the answer is yes. The "skeleton" of the markup is in _main.php, just like in the case of "site-default" profile.

Well, I'm not sure what you are referring to by "main.php", but Ryan's blog post can be understood by looking at the "site-default" profile. You might want take a close look at it. There is a _main.php file used by this profile, the whole article should be viewed in this context.

Quote: "Let's say that I'm using a _main.php file that serves as my primary document markup, like used in our current default site profile. It contains the main document markup, like this:" Ryan normally calls it _main.php (see: $config->appendTemplateFile = '_main.php') and this is where the skeleton of the HTML goes. This skeleton is extended and changed by writing code in the template files assigned to public pages, such as home.php. Otherwise you got it right I think.

While I generally agree with @Beluga's reply, it should be mentioned that it is hard to control the conversation of a chat room regarding what sort of topics can be discussed there. So I do understand @Doug G's concerns, especially as @Pete mentions: "...or get help in a hurry if someone's there."

Hi @EyeDentify I think you got it totally right, at least this is also my understanding of it. EDIT: I missed this one: "...full" HTML markup in the home.php" This "full" markup is supposed to be in "_main.php", but I suppose it was just a mistake that you referred to "home.php".

How about this?

Sure But this is the easiest Anyway, other options are in the thread we linked to.

Hiding them by CSS (display: none)?

Hi, is it the same question? If so, just read the topic. Edit: @kongondo beat me

Hi Kongondo, I'm interested, although I have not used PadLoper yet, I might want to use it when time comes to get rid of any of "my Woo shops". Not in the near future though.

LostKobrakai did not mention MVC at all, probably he did not even refer to it , as far as I can see. Speaking of MVC, I'm not convinced that "strict MVC" is that much useful either, and I'm not alone eg.: http://paul-m-jones.com/archives/6288 But either way, I do agree with @Robin S that lots of brochure websites do not need MCV or the alike, and even webshops can be successful without them especially if one does not have to refactor too much in it the future for some reason. When a system is based on solid system design (meaning the site does what the client needs in the first place) then there is less to worry about regaring possible refactoring. But it is getting off-topic here...

Hello @darkmesaia I often recommend these to start with: Important concepts: https://www.smashingmagazine.com/2016/07/the-aesthetic-of-non-opinionated-content-management-a-beginners-guide-to-processwire/ Understanding Processwire Templates, Fields and Pages: https://medium.com/@clsource/understanding-processwire-templates-fields-and-pages-201aecd0a1a4#.m9yquavll Step-by-step guide, 4 part tutorial: http://blog.mauriziobonani.com/processwire-basic-website-workflow-part-1/ Approaches to categorising site content:

https://processwire.com/blog/posts/processwire-3.0.49-introduces-a-new-template-file-strategy/#Comment12849 By Ryan: "What's described in this post is not a template engine, and not even related to a template engine. Actually it should work quite nicely alongside a template engine if you are using one. What markup regions do is essentially the same thing that the existing PW region() function does, but with some added flexibility and simplicity." If it can be used together with a template engine, then it is the way to go I think. While teaching to fish instead of simply feeding is good a concept, when there are so many different ways to fish, you have to start teaching by using one method only so that all the newcomers can learn the same thing at least at the beginning. This new method/strategy reminds me of Magento, but it is a lot simpler to implement. I do support it. Let's teach people (ourselves to begin with) how to use it with and without a template engine

Hi, a related dscussion:

Does this work on PW 3.0 though? One part says: It should. See: https://github.com/processwire/processwire-issues/issues/75

By Ryan: "... the $config->userAuthSalt (which appears at the bottom of your /site/config.php file). That particular value is generated randomly when you first install ProcessWire. It is forever tied to the passwords as a secondary salt. It's not technically necessary to have it, and passwords are already blowfish'd, but I've always felt better having one part of the salt disconnected from the database itself. If that salt changes or is lost, then all the passwords are forever broken."

It is worth mentioning that the original image looks very soft too. The "original" image must have been downscaled with either very little sharpening or none at all. So further downscaling the original image this way makes it look even softer, especially on high dpi screens.

Hi UIkit 3 users In v2 there used to be a file called uikit-variables (actually two files, a less and a sass version). I liked it this way, because I could simply use my text editor's find all feature to look for what I was interested in. In v3 all the variables are declared in separate files found in the components directory. So I hacked together a simple bash script to collect all the variables in a single file, just for reference purposes, so that I can still do my search in one file only. Should anyone want to do the same, please feel free to use it: #!/bin/bash # Author: Szabesz, release date: 2017-01-12 # Use at your own risk! # Purpose: This script collects all the variables used by UIKit 3 # Configuration: adjust the variables called SOURCE_DIR, TARGET_DIR and FILE_NAME # Usage: run the script and find the result in the generated output file: $TARGET_DIR/$FILE_NAME # How it works: it finds all the 'less' files we need in the folder called 'components' (specified by $SOURCE_DIR) # then grep filters all the lines beginning with @ # in each line, the first occurrence of ':' is replaced with ': ' by sed, so that we have some extra space # finally lines are outputted into a file # Known issues: tested only on macOS 10.11 and Bash 4.x # @media queries are also included, but I consider this to be an added bonus :P # Credits: https://getuikit.com/ set -e; printf "Collecting all variables used by UIKit 3...\n" SOURCE_DIR="/path/to/uikit/src/less/components" TARGET_DIR="/path/to/target/folder" FILE_NAME=_UIkitVars_$(date "+%Y-%m-%d_all.txt") cd $SOURCE_DIR if [ -f $TARGET_DIR/$FILE_NAME ]; then rm $TARGET_DIR/$FILE_NAME fi find . -type f \( -iname "*.less" ! -iname "_import*" \) | xargs grep -E "^@" | sed 's/:/: /' >> $TARGET_DIR/$FILE_NAME printf "End of script has been reached :)\n" exit 0

Thanks @adrian Useful new features as always. You cannot help it but help us

@joer80 There is a recent, related conversation here: "Stripe Checkout" https://stripe.com/checkout is one of the easiest to implent. "Easy to implement: You can integrate Checkout in a few lines of JavaScript. Checkout generates normal Stripe tokens for use on your server." https://stripe.com/us/pricing

@LostKobrakai Lots of valid points, still... I think this option should at least be considered by taking a close look at it. What if the chosen framework can be extended, rather than hacked?