Leaderboard

That's very interesting! Thanks for the resource link, I'll definetly check it out and let you know!

Personally when I install a CMS I prefer to set it inside a subdirectory rather than the root folder. There are different reasons for this choice. For example you may wish to have different CMS installed in different subdirectories; or multiple copies or versions of Processwire in different subdirectories; keep separated directories for production and development; and so on. Sometimes this choice is taken also to obfuscate your CMS contents. In this forum I found some helpful hints, but I could not find a turn-key tutorial explaining the detailed steps for redirection and how to hide subfolder in urls' segments. It's pretty easy. Just let's do it step by step. We are going to create a new .htaccess file in the root folder (please note it is a new one, we will leave the .htaccess file in Processwire subfolder unchanged), where we will add the section described below. Just replace yoursite.com and yoursubfolder with ... your ones! # .htaccess in root directory # Redirect to Processwire subdirectory <IfModule mod_rewrite.c> RewriteEngine On RewriteCond %{HTTP_HOST} ^(www.)?yoursite.com$ RewriteCond %{REQUEST_URI} !^/yoursubfolder/ RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule ^(.*)$ /yoursubfolder/$1 RewriteCond %{HTTP_HOST} ^(www.)?yoursite.com$ RewriteRule ^(/)?$ yoursubfolder/index.php [L] </IfModule> With this approach we can protect root files and subdirectories from redirection. Are we done ? Yes and no. After these modifications pages are redirected correctly, but in the browser link you will note that subfolder's name is still showing. This is not good, we want to hide it. We are just one step away. Let's open our site/config.php and add the following line at the end: /** * Set urls root to hide Processwire folder * This must be combined with .htaccess in root directory */ $config->urls->root = '/'; Do not forget to lock site/config.php after modifying it. If you prefer, instead of modifying config.php, you can place the above line in _init.php. And here it is! I hope this simple tutorial can be of help.

Hi all, I created a custom Fieldtype / Inputfield combo (similiar to https://processwire.com/modules/fieldtype-events/) and also want to add content to this fieldtype via API. Now, with lazy loading enabled I get the error that class is not found. //will throw an error here.. Class ProcessWire\Event not found. $event = new Event(); With lazy loading disabled via config.php everything works well. Is there any way to "register" or make ProcessWire aware to actually load this class or any other workaround (besides disabling lazy loading)?

This module for ProcessWire enables the debug mode to bypass the restriction to install modules. This is useful if you are tired to manually set the debug mode in the configuration. Note Please note that this module doesn't replace the real debug mode in the configuration file /site/config.php. With this module you will not receive any errors/notices/warnings like in the real debug mode. It serves only to bypass the restriction to install modules. Installation To install this module you have to enable the real debug mode. After installation you should deactivate debug mode again. To enable the real debug mode, download /site/config.php via FTP and open it in a text editor. Look for a line where you can find $config->debug = false; change it to $config->debug = true; save the file and upload it again. After module installation change it back to $config->debug = false;. For all future module installations, you just have to enable the debug mode in the module settings like described below. After module installation, you should deactivate it in the same way. Settings The settings for this module are located in the menu Modules=>Configure=>DebugModeSwitch. Enable or deactivate debug mode Set the checkmark (1) and click the submit button (2) will enable the debug mode (3). The debug mode can be also restricted for superusers only (4). Links ProcessWire module directory: https://processwire.com/modules/debug-mode-switch/ Github: https://github.com/techcnet/DebugModeSwitch

Hi @Val_0x42, Yep, please ignore my suggestion or question. It is totally fine to use PWs user, maybe a role with only guest rights, but able to register and authenticate. With guest rights, they can see nothing in the backend. To the other points: I like to code old schooled. ? First send a complete form with checkboxes and submit button, so that it also will work without JS, or, more interesting today, when any early JS throws an error and it stops further execution. Then also a "modern page" maybe left unusable when the bound events cannot run, or even got not bound to the checkboxes, etc.. The next step for me would be to disable the submit button on DOMContentLoaded, collect all checkboxes and add a change event to them, for example: (code not tested, written in the browser) ... <form id='myForm'> <label for='i1234'><input id='i1234' type='checkbox' value='1234' /> YOUR CONTENT HERE </label> <label for='i1235'><input id='i1235' type='checkbox' value='1235' /> YOUR CONTENT HERE </label> <label for='i1236'><input id='i1236' type='checkbox' value='1236' /> YOUR CONTENT HERE </label> <label for='i1237'><input id='i1237' type='checkbox' value='1237' /> YOUR CONTENT HERE </label> <label for='i1238'><input id='i1238' type='checkbox' value='1238' /> YOUR CONTENT HERE </label> <input type="submit" name="submit" id="submit" value="SEND" /> </form> <script type='text/javascript'> document.addEventListener('DOMContentLoaded', function(event) { const myForm = document.getElementById('myForm'); myForm.getElementById('submit').style.display = 'none'; // or, for better A11y support, visibility = hidden, plus shrinking the sizes, or move it out of viewport const checkboxes = myForm.querySelectorAll('input[type="checkbox"]'); for(i = 0; i < checkboxes.length; i++) { // add on change event listener for each checkbox in the form: checkboxes[i].addEventListener('change', function(event) { // get the ID and the status (checked|unchecked) and send via AJAX to update the server. Done! :-) }); } }); </script> </body> </html> Hope that helps to get started. ?

Above should throw an error that you need to set output formatting of before attempting to modify the page. I am guessing you are testing with debug off. Try below. It should work. <?php namespace ProcessWire; $b->of(false); $b->images->add($newpreviewimage); $b->save();

Me to. Just recently I've read two PRO module forum posts where the PRO modules did not work properly with lazyLoading enabled. I am surprised that Ryan enabled it by default, as usually he does the opposite, like in the case of Markup Regions, Page Classes and Functions API. Why should useLazyLoading be en exception to this? Now I need to add $config->useLazyLoading = false; to all the configs of all "my" sites to be on the safe side.

What does that original: bd($_SERVER['PHP_SELF'] . ' : ' . $this->wire('config')->urls->root . 'index.php'); return now?

@jploch - thanks for those. I am honestly not sure the best approach to fix this. The problem in question is this: // check if request is to a PW page - otherwise it's maybe an AJAX request to an external script $isPwPage = $_SERVER['PHP_SELF'] == $this->wire('config')->urls->root . 'index.php' ? true : false; But, I can't seem to trigger a situation at the moment where this returns false (even making an ajax request to an external script). I don't think I want to replace PHP_SELF with SCRIPT_NAME because I think that would return an incorrect result if the external script was an index.php file. Possibly you could add: $_SERVER['PHP_SELF'] = '/index.php'; to the frontControllerPath() method. I expect that will fix things, but not sure if there might be some side effects, but it might be the best solution. Let me know it that works for you.

Interesting - Valet seems to mess with PHP_SELF. Could you please find out what bd($_SERVER['SCRIPT_NAME']); returns. It looks like there might be another option around setting: 'usePathInfo' => true in general.php (https://github.com/laravel/valet/issues/340) - is that something you are familiar with? I think general.php is a file in the Valet system, but not really sure.

Hi @jploch - it looks like the issue is a problem with what $_SERVER['PHP_SELF'] is returning. Could you please add the following code to line #53 of the RequestInfoPanel.php file and let me know what is returned? bd($_SERVER['PHP_SELF'] . ' : ' . $this->wire('config')->urls->root . 'index.php');

Hello boys and girls, here's my newest: https://drinkbodegabay.com/ Bodega Bay is a Hard Seltzer drink that's delivered sustainably and contributes to projects to move climate solutions forward and help those less fortunate than ourselves. The website was built with my customary repeater based content blocks solution. The frontend is based on webcomponents built with StencilJS, and as always, it was a pleasure to build. An interesting detail was the processing we had to make on the locations listed in the Where to Buy section. Basically we were handed an Excel list of locations with irregular addresses that had to be geographically located on google maps. Well, maps doesn't really agree with doing that much processing at once, so we had to convert each location's address into coordinates. We built a script that imported everything to pages, then another one that made requests to grab the coordinates from google maps, store them and move on. As Maps defends itself against multiple requests, this script had to wait, pick out the locations that were already georeffed, and repeat a few times until all were processed. In the end, only a couple of locations had to be manually referenced, as Google wasn't able to find them from the way the address was formed. Another detail was the interstitial we have here. Being an alcoholic drink, this must have an age verification popup. It also needed a cookies popup and language selection. So the solution here was to combine all that in an interstitial (languages are disabled now until they translate everything), where the user is redirected on the first time to get that out of the way, but with user agent testing it lets scrapers pass. I'm a bit worried this might cause problems down the line, so we're keeping an eye on it and will reconsider this solution if need be. Hope you like it. I'll have an even better one to show real soon ?

Hello @ryan, first of all huge thanks for a great addition to the core, but I'm a bit concerned if lazyLoading should be enabled in the core by default as it is since 3.0.194. To give an example where I'm having problems - I have a small function that renders site main menu, where I do check if page templates allows to have a children pages (template noChildren value), if not - they are not rendered in main menu (this is my basic setup for pages like blog posts, portfolio items etc. - these are treated as final pages with no children allowed). The part of the code that renders site menu looks like: if ($item->hasChildren()) { $id = $item->template->childTemplates; $fields = wire('templates')->get($id); foreach($fields as $field) { if (!empty($field->noChildren)) { $no_children = true; } } } Unfortunately since this update, I can't access page templates settings fields values as long as I'm not on that exact page, so in this example all my blog posts are rendered in menu while I'm not on a blog post page. Disabling LazyLoading: $config->useLazyLoading = false; in my config fixes this and brings previous behaviour. Not sure if this is a bug or it was intended, or something is wrong with my code ? but for me one of the most powerfull option of PW is a fact, that I can access anything -page/field/template from anywhere. If that was intended I guess that that other people could have similar problems. While this is a great improvement in overall loading speed, I think that this option should be disabled by default (if it may cause that kind of side effects), and to be left to the final user to decide, if it is needed and should be enabled - same as we don't use cache by default. I would love to hear yours and others opinion in this matter. Thanks!

Hello @Val_0x42, You could make an AJAX call on your page at the change of a checkbox and save the user data then instead of the form submission. I would also use regular ProcessWire users to get the benefits of access control. Regards, Andreas

@horst Thank you. I think Curl may do the trick. This will give me something to learn.

@jploch - it should be fixed in the latest version.

Hi @jploch - I actually have a feeling this isn't Valet related. It looks like a bug in the RequestInfo panel. Any chance you have turned off some of the sections within it, likely the Template Settings section? It's an easy fix, but just wanted to confirm that you do have this disabled. It's probably that one second from the top that is causing the problem. You might have upgraded from a really old version of Tracy when that section didn't exist.

Hey horst, thanks for the reply! Ok I'm happy to see that the solution is pretty much what I thought except for the form part (I was using simple checkboxes). I'll try to manage checkboxes as a form and see how the whole submission mechanic works! I'd also like to make it so it would update "live" and the users wouldn't be forced to submit the checks (by save button I mean) before changing page and risk losing their data. For now I'll start simpler and build up from the easiest working solution. May I ask if there's a specific reason why you suggested to separate processwire users from the visitors? I thought that having them as standard users would have made it simpler to check who was logged in and get their selections. Also I'm wondering if there's maybe a way to trigger form submission on page change so that the user experience would flow more easily. In the meantime I'll start searching on how to code the solutions you suggested, thanks!

Maybe this scenario can be starting point? Create a parent page that holds all items, each as a page. Create a parent page for visitors (users, but maybe not PW user?), that holds every visitor as a page. Create a page reference field for the items. Add this page reference field to the visitor template. Show the visitor a page with a normal HTML form, showing a regular checkbox for each item. On form submission, check which ones were selected and for each of that, add its ID to the page reference field of the current visitor. On a second visit of that visitor, you can present him/her the form with all collected items preselected (checked checkboxes). SO he/she is able to add and remove items to / from the collection. On form submission simply clear the old state of the reference field and build it up new. That's a raw starting point that has potential for additions and modifications. But for me it looks uncomplicated and straight forward for what you try to achieve, if I have understand it correct. ?

The backend is basically just a uikit navbar + content: https://getuikit.com/ You can simply include the backend theme files and use them for your frontend. You can even use the Less module and you get all the power of Less and variables etc. See https://github.com/baumrock/AdminStyleRock#how-adminthemeuikit-styles-work for details

@fuzenco You may also use CURL, or maybe WireHttp, also a wrapper around CURL. BUt not really sure about wireHttp here! Otherwise the phpseclib for sftp is good to go, but maybe a bit to much overhead in this case, compared to CURL, if available? https://everything.curl.dev/usingcurl/scpsftp https://unix.stackexchange.com/questions/56261/automated-sftp-upload-with-curl

@sz-ligatur It depends on the PW version. fopen used to be the default, but it's more and more common for allow_url_fopen to be disabled, so I've switched the default to CURL (when available) on the dev branch. In any case, with CURL, the flag that you set raw data with also makes it use POST, so I'm not sure how you send raw data (other than a file resource) with CURL using PUT, so you probably should make use use fopen for that case. You can force it to use fopen by specifying ['use' => 'fopen'] for the $options argument to WireHttp::send().

I think this one little upgrade is worth being mentioned in the blog post. If I get it right, we are finally able to address page save and field save events for the page in one hook! Wow!