szabesz

I guess you have an up-to-date version of MAMP (which I do not have at the moment since I do not upgrade MAMP too often) https://www.mamp.info/en/downloads/ And reading the sidebar, it ships with PHP 7.0.0 too. Do you happen to use it? I run ProcessWire 3.0.5 on PHP 5.6 and do not have any "deprecated notices". Anyway, since it is just a "deprecated notice", it should not be the cause of a 500 Internal Server error, but you might want to try switching to PHP 5.6. Have you tried to install ProcessWire from scratch, so that you can see if that works? Edit: PHP 7 maybe just an optional addon, and it does not yet ship with it.

The docs says: $page->of(false); // outputFormatting must be OFF https://processwire.com/api/multi-language-support/multi-language-fields/#getting-and-setting "The value of a multi-language or language-alternate field is affected by the "outputFormatting" setting of a page. On the front-end of your site, outputFormatting is always turned on, unless you've turned it off." "When outputFormatting is ON, the value of a multi-language field is a string (as it shows in most examples on this page). That string reflects the value from the current user's language. If the value is blank in the current user's language, the value from the default language will be there instead. However, when outputFormatting is OFF, the value of a multi-language field (like $page->body) will instead return an object of type LanguagesPageFieldValue, rather than a string. That object contains all of the translations available for the given field." I'm not sure that this solves anything, I'm just guessing. Sorry if I'm mistaken.

What sort of errors are you getting? You can find the log files here: /Applications/MAMP/logs/apache_error.log /Applications/MAMP/logs/mysql_error.log /Applications/MAMP/logs/php_error.log or just use MAMP's Log menu.

Thank you again Ryan! May I ask a couple of feature related questions? I have just tried out this module for the first time and noticed the following: 1) It is not possible to exclude modules. Admin related modules are not needed in many cases (such as ProcessDatabaseBackups, ProcessWireUpgrade, ProcessExportProfile, etc...) and it would be nice to be able to optionally exclude them. 2) Custom folders? Since I followed what is recommended here: https://processwire-recipes.com/recipes/best-way-to-implement-a-global-helper-function/ I already have one custom folder called "lib" in my /site folder and my template files use its content. However, the exporter ignored this custom folder. Did I overlook something or is it really the case and I have to manually copy "such things" over? 3) Extra lines inserted into the end of config.php? I also have extra lines inserted into the end of config.php. It would be nice, if it was possible to optionally inject these extra lines of code to the end of config.php, so that the ProcessWire installer uses the "core config.php" file, but modifies it by adding extra lines to it, lines that are required by the Profile. I have a require_once(dirname(__FILE__).'/lib/Flog.php'); piece of code, and although it is possible to include config.php in the Profile itself, being able to automatically "extend" config.php during the installation process seems to be a better solution. Or maybe I am just overlooking something Sorry if it is just a silly request and there is already a proper way of doing this, of which I know nothing about. Edit: maybe it is not just config.php but .htaccess too that we should be able to extend the above described (or similar) way.

There is an article about the role of Page in the old Wiki. It is still a good starting point, even though it is a bit hard to understand this article without some actual experience with Pages: http://wiki.processwire.com/index.php/Pages_Overview What I would find useful is the addition of schematic diagrams that help beginners picture the concept. Trying to explain it by using only words resulted in this sort of convoluted article. A picture is worth a thousands words Not to mention lots of simple examples, that help explain different scenarios in which Page is used.

This one is also worth reading: URL Segments in category tree example: http://wiki.processwire.com/index.php/URL_Segments_in_category_tree_example

@benbyf You might find this class useful if you want to introduce the classic way of php debugging: https://processwire.com/talk/topic/4550-debugging-tips/?p=110290 Another thing that might be of interest is a short introduction to the main components of ProcessWire. What important building blocks are used in the CMS/framework, what they are for, how they work together, and which ones should be further studied as starting points, how modularity is implemented (CMS vs CMF). Such as: message system, logging system, 3.x compilation, wire calls, etc... Something similar: cms architecture diagram And links to Ryan's blogpost or other related doc pages for further study. I have not found anything similar so far, and it would help me a lot, I'm sure

I have further refined this class. For instructions, you can read the comments in the code, or this: https://processwire.com/talk/topic/11782-pw-tuts-elsewhere-on-the-web/?p=110131 <?php namespace ProcessWire; /** * Flog.php: Can be used to inspect variables for debugging purposes. * * Example usage: * - If NOT running ProcessWire 3.x or higher, remove namespace ProcessWire; * - Create a directory called lib in your /site directory and put Flog.php into it. * - Insert this line into config.php: require_once(dirname(__FILE__).'/lib/Flog.php'); * - In the case of frontend debugging, start the rendering of the output * by calling Flog::init() before your code does anything else (for example * it could be the first line in your _init.php). * * - example log entry for PHP 5.5.x and below: Flog::log($page->children(), 0, 'kids', __FILE__, __LINE__); * - example log entry for PHP 5.6.x and above: Flog::log($page->children(), 2, 'kids', __FILE__, __LINE__); * * TIP: Use a shortcut to insert this code snippet into your code: Flog::log($var, 0, '', __FILE__, __LINE__); * then edit the first three parameters accordingly. Read all the other notes below for more information. * */ class Flog { protected static $name = 'flog'; // name of the log file protected static $firstSave = true; // no variables have been logged so far? /** * Initializes the class. Call it once before you start calling Flog::log() * The log file can be found in /site/assets/logs/flog.txt (assuming $name = 'flog') * */ public static function init() { if(!file_exists(self::filename())) { self::log('f-log debug file created...'); } @ini_set('error_log', self::filename()); // so that the same file is used for runtime errors as well } /** * Call Flog::log($my_variable) to log a variable. * * NOTE: the Wire class customizes the output of print_r (__debugInfo) when running on PHP 5.6+, so the $print_r * parameter can be used to output objects this way. * * @param mixed $var Any variable or expression to be logged. * @param 0|1|2 $print_r 0: print_r is not used, 1: print_r's output in one line, 2: formatted print_r output. * @param string $info Any string that helps identify the output, such as a variable name. * @param string $file Should be __FILE__ to identify the caller. * @param string $line Should be __LINE__ to identify the caller's line. * */ public static function log($var, $print_r = 0, $info = '', $file = '', $line = '' ) { $type = ''; $pretty = false; $php56plus = version_compare(PHP_VERSION, '5.6.0') >= 0; if (gettype($var) != "object") { $type = "[".gettype($var)."]"; } else { $print_r >= 1 && $php56plus ? $type ='' : $type = "[".get_class($var)."]"; } if (is_array($var)) { $var = json_encode($var); } elseif ($print_r >= 1 && is_object($var) && $php56plus) { if ($print_r == 1) { $var = print_r($var, true); // reformat whitespaces: $var = preg_replace('/\s+/s', ' ', $var); $var = str_replace(" => ", '=>', $var); } else { $pretty = true; } } if (self::$firstSave) { self::$firstSave = false; wire('log')->save(self::$name, "________________________ Flog.php _______________________"); } if ($file) { $file = basename($file, '.php'); } if ($pretty) { error_log(print_r($var,true)); // works in PHP 5.6.x and higher } else { wire('log')->save(self::$name, "$file $line $info $type $var"); } } public static function filename() { return wire('log')->getFilename(self::$name); } public static function name() { return self::$name; } }

Edit: an updated version of the the following class can be found here: https://processwire....-tips/?p=110290 <?php namespace ProcessWire; /** * Helps with the debugging log */ class Flog { protected static $name = 'flog'; protected static $firstSave = true; public static function init() { if(!file_exists(self::filename())) { self::log('f-log debug file created...'); } } public static function log($param, $file = '', $line = '') { $prepend = ''; if (gettype($param) != "object") { $prepend = gettype($param); } else { $prepend = get_class($param); } if (is_array($param)) { $param = json_encode($param); } if (self::$firstSave) { self::$firstSave = false; wire('log')->save(self::$name, "________________________ Flog log _______________________"); } if ($file) { $file = basename($file, '.php'); $line = $line . ' '; } wire('log')->save(self::$name, "$file $line"."[$prepend] $param"); } public static function filename() { return wire('log')->getFilename(self::$name); } public static function name() { return self::$name; } } The original class was dubbed Debug, which is used in the ProcessWire namespace, so I had to rename it. The "Flog log" line helps me quickly identify the various "logging sessions". File and line number can be used to identify the states of the same variable and later on to clean up (delete) all the temporary log method calls. I use a shortcut to quickly insert Flog::log($var, __FILE__, __LINE__); into the code, I just have to overwrite the variable name, and save+refresh the browser (using a shortcut in this case too). A code editor is used to keep the log file(s) open, which refreshes the open files whenever they change. I can delete lines from the log at will, since it is an actual editor. Simple but effective, I got used to this a debug workflow, since it can be used in any environment.

One more thing to add. Yesterday I decided to utilize clsource's class: https://processwire.com/talk/topic/4550-debugging-tips/?p=108300 I added namespace ProcessWire; to it and modified it a tiny bit so that I can also log the class/type name of the logged variable, and the file and line number of the caller. Recommending an easy to use method for debugging (that even works in production, on whatever server this site might be running) seems to be a good idea to include.

I think clsource and rick are right; even a tutorial for those new to ProcessWire should assume a general understanding of entity relationships, procedural programming, html and css, and it should concentrate on the methods and design patterns that beginners can easily implement to craft a site with typical components such as general pages, blog posts with categories and tags, a simple contact form and maybe a simple user management to protect a given page (and its children) on the frontend ("customer area"). By choosing a css framework, you can skip the design process altogether.

Would it be a "basic setup" similar to those page builders that are so popular these days in WP/Joomla and (possibly) others? Interesting idea.

Thanks once more

Thanks for letting us know!

I read the article so now at least I get the basics of this new feature. Issue 1 One thing is really confusing about how it works: - I deleted the "FileCompiler" folder in "cache" - I set the compile option of a template to "Yes (template file only)" - "FileCompiler" folder and its content was re-generated - I reloaded a page of the frontend and the wireRenderFile("partials/top_nav.inc.php", $_p); call ran fine - I set the compile option to the default "Yes (and included files)" - I reloaded a page of the frontend and the cached/compiled version of the template file of that page did NOT change. I suppose this is because the original template file did not change either. However, this can be confusing, because later on I might easily change the original template file, and the cached/compiled version will change to this (which fails to run): $layout = wireRenderFile(\ProcessWire\wire('files')->compile("layout/home.inc.php",$_p,array('includes'=>true,'namespace'=>true,'modules'=>true))); So the problem will only crop up later on, just to "surprise me" a little bit, which is not the best experience ever Issue 2 I have just created a gif screen-grab to show you what happens when I try to use the "No" option:

Thanx a lot! I'm going to read it.

Thanks clsource! It would be nice to learn more about this compilation feature. So far, I have not found anything that describes it in detail. Any good articles or forum posts on it?

It took me a while to figure out what causes wireRenderFile() to fail processing its second (optional) parameter in ProcessWire 3.0.3, but finally I could pass those variables to the template file by using the "Yes (template file only)" option of "Use Compiled File?" setting in the admin panel. The default setting is "Yes (and included files)", but with this setting selected, wireRenderFile() cannot receive its optional array parameters. Is it a bug or a feature? I also tried to switch to "No", but this option cannot be saved, after saving the template it switches back to "Yes (and included files)". Again, bug or feature? All my template files begin with <?php namespace ProcessWire; so in this case is this automatic namespace updating necessary at all? I don't know how this compiling thingy works, so I do not know what the right answer to this "Use Compiled File?" question should be. Is it ok to use "Yes (and included files)"? Or should I use "No" (if it was possible)? Or "Yes (and includes files)" which renders wireRenderFile() sort of useless? Any help is appreciated!

@rick: In this case we are back to square one, that is "processwire shouldn't be implying endorsement of 'anything else'" which is the current state we are in Without an easy to use ("shape it to your needs") frontend "framework", you cannot guide beginners/non-developers in tweaking the profile they use. In this case, we are talking about bloggers, small companies, etc, who need a reliable, easy to maintain CMS (ProcessWire) and want to tweak the frontend a little bit, but they do not want to "develop" anything. They just need useful tips and code snippets with step-by-step instructions on how and where to apply them. I know, this is not the basic idea behind ProcessWire, but the topic here is "PW Site Profiles are like WP Themes?", and we cannot solve it without anything pre-build for the frontend.

Sure, it could (can, actually). But I try to avoid conditionals when there are alternatives. After all, first of all I just want to construct a given page based on partials, and the layout of them can be put together by using various reusable parts which are always the same on a given page (like sidebars, latest posts, banners, etc...). Of course, some "reusable parts" can be pretty complex which surely use conditionals, but complex features are implemented in those partials only (or as separate reusable functions, classes, etc...) and the scaffolding of the page is managed by this simple method which is easy to understand. SilverStripe and Magento uses this method (built upon completely different implementations, of course) and I always found this type of rendering method to be easy to work with, that is why I was happy to learn that we have wireRenderFile() (which is easy to use).

I do not know about others, but I have fallen in love with ProcessWire at first sight However, I hate social media and maybe it is not just me who does so.

Actually, I didn't completely describe my concept, so it looks like it is about replacing _main.php, but it is something else. What I want to achieve is a tree/recursive like template file render method, which starts with $layout = wireRenderFile("layout/home.inc.php") and this $layout is echoed out in _main.php which I - normally - do not want to change since _main.php contains the head(er) and the footer of the site (in case of a "classic" page layout), however each page should be configurable to use its own "layout". The actual "layout file" also contains wireRenderFile() call(s), to render reusable parts of the site. So the rendering process starts with echo $layout and continues down the "partial file tree structure" by using more wireRenderFile() calls to "include" the required template file partials. It is just like using simple php includes with direct output. So it's a rather simple concept, but it can be extended by using a few more variables besides $layout to solve problems like not loading not needed resources into a given page (like not loading jQuery on pages where it is not needed, etc...) I hope I was able to explain it clearly this time.

I have just found this css framework (called Responsee III) the other day (actually, I've been looking for something like this for a while). It is not as "bloated" as (say) Bootstrap or Foundation, so it is easy to figure out what is behind the scenes, as it uses vanilla css so no sass/less or similar is used. This framework is not re-written from scratch every second year either. I tested one of its v2 based demo website by replacing the framework's files with the new versions found in v3, and nothing has changed on the frontend, so even upgrading the framework was as simple as replacing some files. A framework like this would be a good choice to be used for this "quick start site profile". People can customize it easily by using their own "custom.css" to overwrite the rules. Besides the css framework, the profile should support something similar that WordPress does right out of the box (standard blog features with categories). I also support (actually I am implementing my own PW version) a variation of the delayed output, when (e.g) basic-page.php only does this: $layout = wireRenderFile("layout/basic-page.inc.php"); and basic-page.inc.php contains the alternative syntax style template code, which is often preferred by beginners and people coming from WordPress and similar... Edit: I forgot the name and the link of the css framework, so I just added it...

To reply to my own question: for simple selects, this might be a better option, I suppose: https://processwire.com/api/modules/select-options-fieldtype/ https://processwire.com/blog/posts/new-options-fieldtype-processwire-2.5.17/

Thanks Jonathan, I have not yet used repeaters so far, but been wondering for a while when they could be used. Maybe for constructing simple select dropdowns when enum would suffuce?