Leaderboard

I am relativelay new to Processwire and started about 3 weeks ago with it. I tried all tutorials, read a lot in the forums and played around with several provided code snippets here and I must say: Wow! I used to use Wordpress as I could get things done with plugins all the way through but with Processwire I feel like I have everything in control as I "have to" take care of everything I want to accomplish. I spend every free minute learning Processwire and learned more about PHP (and Processwire) than ever before. I wasn't and still be not a programmer but Processwire gives me the ability to become one. I read people saying "Processwire is your CMS of choice" but I think i also helps you to understand the basic of PHP programming. if/else or foreach or whatever... Processwire give me what PHP tutorials are missing. Maybe in a week or two I already can publish my very first and "self programmed" website ever. Without Wordpress or any plugins from other people. Thank you all for giving those verbose code snippets that every newbie understands! P.S. I hope this is the right place to post this. Sorry if not.

---DEPRECATED--- Please use RockSkinUikit Just install the module and you can change the look&feel of your admin instantly by changing only one color: Download: https://modules.processwire.com/modules/rock-skin-uikit/ https://github.com/BernhardBaumrock/RockSkinUikit I'd be very happy if any of the CSS pro's could do some final improvements to the default.less theme - though I'm already very happy with the result! Happy Admin-Theming ? PS: At the moment this downloads a fork of the original AdminThemeUikit module because one method is not yet hookable. You can support this request here: https://github.com/ryancramerdesign/AdminThemeUikit/pull/77 and then I can update my module to pull the original theme from ryan.

Hi @ryan, Could we get the current version numbers back on the master/dev download buttons?

RockLESS Download: https://modules.processwire.com/modules/rock-less/ Docs: https://github.com/BernhardBaumrock/RockLESS

Hey @GynTonyc. Welcome to our community and to ProcessWire. There is a reason why we have chosen PW as our framework/CMS of choice. You already know why. If you have more questions don't be afraid to ask.

This will be more of a quick tip, and maybe obvious to many of you, but it's a technique I found very useful when building display options. By display options I mean fields that control how parts of the page are displayed on the frontend, for example background colors, sizing, spacing and alignment of certain elements. I'll also touch on how to make those options intuitive and comfortable to use for clients. It basically involves setting up option values that can be used directly in CSS classes or as HTML elements and mapping those to CSS styling (which can be quickly generated in a couple of lines using a pre-processor such as SASS). Another important aspect is to keep the option values seperate from their corresponding labels; the former can be technical, the latter should be semantically meaningful. The field type that lends itself to this this seperation of concerns is the Selectable Options field, the following examples mostly use this field type. Note that this module is part of the ProcessWire core, but not installed by default. The following examples all come from real projects I built (though some are slightly modified to better demonstrate the principle). #1: Headline levels & semantics For a project that had many pages with long texts, I used a Repeater field to represent sections of text. Each section has a headline. Those sections may have a hierarchical order, so I used a Selectable Option field to allow setting the headline level for each section (you can guess where this is going). The definition of the options looks something like this (those are all in the format value|label, with each line representing one option, see the blogpost above for details): h2|Section headline h3|Sub-section headline Of course, the PHP code that generates the corresponding HTML can use those values : // "sections" is the repeater field foreach ($page->sections as $section) { // create an h2 / h3 tag depending on the selected option (called headline_level here) echo "<{$section->headline_level->value}>{$section->headline}</{$section->headline_level->value}>"; echo $section->body; } That's a pretty obvious example, but there are two important takeaways: I only used two options. Just because there are six levels of headlines in HTML, doesn't mean those are all relevant to the client. The less options there are, the easier it is to understand them, so only the options that are relevant should be provided. In this case, the client had provided detailed, structured documents containing his articles, so I could determine how many levels of hierarchy were actually needed. I also started at h2, since there should be only one h1 per page, so that became it's own field separate from the repeater. The two options have a label that is semantically relevant to the client. It's much easier for a client who doesn't know anything about HTML to understand the options "Section headline" and "Sub-section headline" than "h2" and "h3". Sure, it can be cleared up in the field description, but this way it goes from something that's quickly explained to something that needs no explanation at all. #2: Image width and SASS In the same project, there was also an image section; in our layout, some images spanned the entire width of the text body, others only half of it. So again, I created an options field: 50|Half width 100|Full width In this case, I expected the client to request different sizes at some point, so I wanted it to be extensible. Of course, the values could be used to generate inline styles, but that's not a very clean solution (since inline styled break the cascade, and it's not semantic as HTML should be). Instead, I used it to create a class (admittedly, this isn't strictly semantic as well): <img src="..." class="w-<?= $section->image_width->value ?>"> With pure CSS, the amount of code needed to write out those class definitions will increase linearly with the number of options. In SASS however, you only need a couple of lines: @each $width in (50, 100) { .w-#{$width}{ max-width: percentage($width/100); } } This way, if you ever need to add other options like 25% or 75%, you only need to add those numbers to the list in parenthesis and you're done. You can even put the definition of the list in a variable that's defined in a central variables.scss file. Something like this also exists in Bootstrap 4 as a utility, by the way. It also becomes easier to modifiy those all at once. For example, if you decide all images should be full-width on mobile, you only need to add that once, no need to throw around !important's or modify multiple CSS definitions (this is also where the inline styles approach would break down) : # _variables.scss $image-widths: (25, 50, 75, 100); $breakpoint-mobile: 576px; # _images.scss @import "variables"; @each $width in $image-widths { .w-#{$width}{ max-width: percentage($width/100); @media (max-width: $breakpoint-mobile) { max-width: 100%; } } } One important gotcha: It might be tempting to just use an integer field with allowed values between 10 - 100. In fact, the amount of SASS code would be identical with a @for-directive to loop throuh the numbers. But that's exactly what makes point-and-click page builders so terrible for clients: too many options. No client wants to manually set numerical values for size, position and margins for each and every element (looking at you, Visual Composer). In fact, having too many options makes it much harder to create a consistent layout. So in those cases, less is more. #3: Multiple options in one field Another example for repeatable page sections, this time for a two-column layout. The design included multiple variants regarding column-span and alignment. Using a 12-column grid, we needed a 6-6 split, a centered 5-5 split, a left-aligned 6-4 split and a right-aligned 4-6 split. I didn't want to litter the repeater items with options, so I decided to put both settings in one field (called something like Column layout) : center_6_6|6 / 6 (Centered) center_5_5|5 / 5 (Centered) left_6_4|6 / 4 (Left-aligned) right_4_6|4 / 6 (Right-aligned) As long as the value format is consistent, the individual options can be quickly extracted and applied in PHP: [$alignment, $width['left'], $width['right']] = explode('_', $section->column_layout->value); echo '<section class="row justify-content-' . $alignment . '">'; foreach (['left', 'right'] as $side) { echo '<div class="col-lg-' . $width[$side] . '">'; echo $section->get("body_{$side}"); echo '</div>'; } echo '</section>'; If you don't recognize the syntax in the first line, it's symmetric array destructuring, introduced in PHP 7.1. For older versions you can use list() instead. This example uses Bootstrap 4 grid classes and flexbox utility classes for alignment. The corresponding CSS can be quickly generated in SASS as well, check the Bootstrap source code for a pointer. Again, I'm limiting the options to what is actually needed, while keeping it extensible. With this format, I can easily add other column layouts without having to touch the code at all. #4: Sorting page elements A final example. In this case I was working on a template for reference projects that had three main content sections in the frontend: A project description, an image gallery and embedded videos (each using their own set of fields). The client requested an option to change the order in which those sections appeared on the page. Had I known this earlier, I maybe would have gone for a Repeater Matrix approach once again, but that would have required restructuring all the fields (and the corresponding code), so instead I used a Selectable Option field (labelled "Display order"). My approach is similar to the one from the last example: body_gallery_embeds|Description - Gallery - Videos body_embeds_gallery|Description - Videos - Gallery gallery_body_embeds|Gallery - Description - Videos gallery_embeds_body|Gallery - Videos - Description embeds_body_gallery|Videos - Description - Gallery embeds_gallery_body|Videos - Gallery - Description Since there are six possibilities to sort three items, this is the expected number of options. So I decided to include them all, even though some are probably never going to be used. I also tried to use a predictable order for the options (i.e. the options come in pairs, depending on what element is first). And here is the code used on the frontend: // render the template files for each section and store the result in an associative array $contents = [ 'body' => wireRenderFile('partials/_section-body.php', $page), 'gallery' => wireRenderFile('partials/_section-gallery.php', $page), 'embeds' => wireRenderFile('partials/_section-embeds.php', $page), ]; // e.g. 'gallery_body_embeds' => ['gallery', 'body', 'embeds']; $order = explode('_', $page->display_order->value); // echo the contents in the order defined by the option value foreach ($order as $item) { echo $contents[$item]; } You can see how it will be easy to add an additional section and integrate it into the existing solution. Though a fourth item would result in 4! = 24 possibilities to sort them, so at that point I'd talk to my client about which layouts they actually need ? Conclusion I always try to keep my code and the interfaces I create with ProcessWire extensible and intuitive. Those are a couple of solutions I came up with for projects at work. They are certainly not the only approach, and there is nothing super special about those examples, but I found that putting a little more effort into defining options with meaningful labels and using option values that I can use directly in my templates makes the result less verbose and more maintainable. Some or most of this tutorial may be immediately obvious to you, but if you made it this far, hopefully you got something out of it ? Feel free to share your own methods to create display options, or how you would've approached those problems differently. Thanks for reading!

How about a new favicon of the ProcessWire logo instead of being lost in the clouds? I attached two 512x512 PNG files (PNGs can be used for Favicons by the way and all browsers support it; worth ditching .ico).

@kongondo you should consider crowdfunding this. Kickstarter or whatever. The community needs an official or reputable shopping solution and what you’re doing is so much work without a guarantee that it will pay off for you.

Happy and productive new year! ? I opt for this one: Please do not try to take on too much work before the initial release regarding the GUI. I think one layout is just enough to start with. Besides, if we have two layouts then it will make creating docs an tutorials more complex as we need to account for both. Configurable layout is less desirable than and easy to use one right from the beginning. I would not like to see an app like behaviour as that implies mobile only experience which can never be as productive as a well tailored desktop GUI. Sure, it should be usable on mobiles without any irritating issues but that is of second concern to me.

A great contribution!

There are enough logs to show that the user has used the forgot password tool in the forums which isn't the action of a bot. They also passed the validation when joining and I also checked on stopforumspam.com manually. Aside from that, which rules have been broken? It is annoying to be sure not to receive any thanks, but the easiest thing to do here is simply not reply.

Maybe https://modules.processwire.com/modules/fieldtype-concat/ ? Don't know if that works only on runtime or also for selectors. You could also populate a separate field via saveready hook and then query this field if this does not work with the concat fieldtype (sorry, I've never used it).

Of course it is possible ? Just create a new folder and click reload on the laragon screen. If you enabled https it will even create the certificates for you. And you can even share your site over the web via ngrok instantly (eg for showing your work to clients). But of course you need to create a new database for every project as @jmartsch already mentioned. Well, I understand you, but those things happen ? But you have to be a little careful about your databases in general. If you mess something up, this can be a real nightmare to recover. I'd recommend you install https://modules.processwire.com/modules/process-database-backups/ combined with https://modules.processwire.com/modules/cronjob-database-backup/ . Then you'll always have db backups in your /site/assets folder. You'd still need to backup your files, of course. I wanted to use OneDrive for that, but it did not work well with laragon (too many files, too slow syncronisation, ...). I'm using GIT now for every project. It's complicated in the beginning, but it's the best solution in the long run. So, if you are willing to learn, there are lots of possibilities ?

The language pack is available at https://modules.processwire.com/modules/german/ or in the github repository https://github.com/jmartsch/pw-lang-de/releases/tag/latest The master branch will (try to) be up to date with the most recent stable version of ProcessWire. The dev branch will (try to) be up to date with the most recent dev version of ProcessWire. If you find any missing translations or errors, please create a PR or submit a bug/improvement. I hope we as a community can work together, to update translatations as soon as a new dev branch is pushed. Please let me know if you want to translate a new dev version, so we are not both doing the same task. If you want to help, you can clone my ProcessWire environment for language packs which provides an easy way for translating a language pack. You simply clone it, make changes to the language in ProcessWire and commit the changes back to your (or the german) language pack repository. This is a boilerplate which could work with any language, but right now it is tailored to the german language pack. Then I am able to quickly release an updated stable language pack when a new ProcessWire stable version is released. Big thanks to @Nico Knoll and @yellowled for their initial work on the translations.

Hi all, I have posted this in the VIP support forum of Padloper as well. Some of you do not have access to that board so posting here as well. Hopefully it doesn't count as spamming?! In June 2018, Antti announced that he was looking for a new product owner for Padloper. Sometime after, I had a fruitful discussion with him about my vision for the project if I was to take over. We agreed that commitment, motivation and a concrete plan were all important ingredients for the continued success of Padloper. I would like to officially announce that I am now the product owner and lead developer of Padloper. For those who may not know, I am the author and maintainer of several ProcessWire modules, both free and commercial. I am also a moderator in the ProcessWire forums. I would like to share with you a number of things regarding what’s going to happen next. This will be a long read. First, I would like to thank Antti for developing a great product. A lot of man-hours, dedication, passion and love has gone into making Padloper what it is today. Secondly, I would like to thank all users of Padloper. A great product is nothing without active users utilising it, putting it to the test, reporting bugs (even offering possible solutions) and proposing new features. So, thank you for helping make Padloper great! Support Thousands of hours have gone into developing Padloper. Although the code is well-written and easy to follow, Padloper is a big application with many moving parts. As such, it will take some time before I can fully grasp its inner workings. To make this transition as smooth as possible, Antti will help me with support for Padloper for some time. Currently, Padloper has a dedicated support forum. This is an arrangement between Ryan and Antti. The support forum works great as it allows the opening of multiple support threads to cover different issues. I have yet to speak to Ryan whether this arrangement can continue. However, given that I have other pro modules that I support in the open forums, it is unlikely that I will be requesting Ryan to let Padloper’s dedicated forum carry forth. A dedicated forum for one of my pro modules and open forums for my other pro modules will lead to confusion and questions from users of those other modules. Hence, Padloper support in the forums will move to the open forums. The disadvantage here is obviously the fact that support will be offered in one single (and maybe massive) support thread. To get around a ‘single thread support forum’, I am thinking of developing a simple online support queue system for all my modules. Meanwhile, support will continue in a new single thread and via email. Roadmap This list is neither exhaustive nor cast in stone. Its aim is to give an overview of my plans for Padloper. · Padloper 2 – a new major release · New backend for Padloper · Optional pro frontend module for Padloper · Documentation · New payment modules Let’s talk a bit about this list. Padloper 2 Release Padloper 2 will be a major release that incorporates a new, central backend shop for Padloper. This will be a new process module that pulls from the existing parts of Padloper (data models, etc) into one interface (more on this below). This version will also be extensible in the frontend, allowing for the plugging in of a new, optional, commercial frontend shop (full featured shop profile). Padloper 2 will not support the current ‘any page can be a product’ paradigm. Technically, products will still be pages. However, all products will utilise the same Padloper template. These will be invisible to the shop users themselves (e.g., hidden in admin tree). Only superusers will have full control of the Padloper system stuff. Support The current Padloper will continue to be supported until the new Padloper 2 is released. New features will be included in Padloper 2 only. Once Padloper 2 is released, legacy Padloper will only receive security fixes. All other support will cease. Upgrade There will be no upgrade path from the current Padloper to Padloper 2. Although their underlying architecture is the same, making sure that everything works in different setups and environments will be time consuming. However, for those who really need to migrate, if time allows and for an agreed fee, I could develop a custom script for the migration. Backend A new backend interface will be the major visual difference between the existing Padloper and Padloper 2. It goes beyond visual differences though. The new backend will be the single gateway for managing all shop-related features, both current and new ones. The backend will unify and include: · Easily add shop products. · Ability to add as little or as many custom fields to products as required (title, SKU, price, discount field, image/photo, description, categories, tags, etc). · Discounts manager (including auto start/expire discount codes). · Customers manager. · Invoices manager. · Taxes management. · Payment gateways manager. · Improved digital products management. · Stock management. · Manual order creation. · Graphical sales report. · Customer support. · Access-controlled shop editors/staff. · Dashboard for shop metrics. · Shop settings. · Product variations. · Import/export products as CSV or JSON. · Products search/filter. · Etc. Users will be able to turn off backend features that they do not need. This will enable a more streamlined experience for users. I plan to release Padloper 2 within 4 - 6 months, hopefully sooner. This is a major undertaking, hence the timescale. Please note that the first release of Padloper 2 will not include all of the above planned features. The idea is to build incrementally, adding new features in minor updates, focusing on stability, usability and security. Frontend Past requests have included the development of a full featured frontend shop. This is planned for Padloper 2. However, this will be an optional pro module priced separately from Padloper itself. The ability to build own frontend shops using Padloper API will still continue. For those who want a plug-n-play solution, this frontend shop will come in handy. The frontend shop profile will feature an ajax-powered shopping cart and a customisable ready-to-go theme. Pricing Model There are no plans to change the current prices of the 3 Padloper licences (Single, Developer and Agency). However, in order to continue to provide Padloper as a stable product with great features, it is also important that it remains a competitive and financially sustainable project. In order for this to happen and to also bring Padloper in line with my existing pro modules, the pricing model itself has to change. Starting from Padloper 2, the pricing model will shift to an ‘annual subscription’ model rather than the current ‘lifetime licence model’. I am fully aware that there are different opinions for and against annual subscriptions. However, I believe that this model is the most equitable approach that suits both the developer and the clients. The annual subscription will allow users (licence holders) to get 12 months of free VIP support for Padloper as well as future updates available within that time period. After the 12 months, users will be able to renew (online) their subscription at a discounted cost (worked as a fraction of the full purchase price) for a further 12 months (perpetually). Users will be able to continue to use Padloper for life even if they don’t renew their subscriptions. Upgrading current licences to Padloper 2 will be a paid upgrade. Current users of Padloper will get an attractive discount. This will be a time-limited offer (maybe a couple of months) that will start with the release of Padloper 2. New customers will pay the full price for Padloper 2. I hope the planned features are reason enough for you to consider upgrading to Padloper 2. Payment Modules I will be taking over as the maintainer and lead developer of the existing payment gateways (Payment base class, PayPal and Stripe). New payment modules are also planned. Payment modules will continue to be free. However, only ProcessWire 3+ support will be provided going forward. Padloper Domain and Future Downloads I have also taken charge of the Padloper domain. Within the next 12 months, purchase and download of Padloper will shift to processwireshop.pw. Please note that this is not the official shop for ProcessWire! It just bears a name that reflects its product offerings ?. Eventually, traffic to padloper.pw will redirect to processwireshop.pw. Feedback I would love to hear your thoughts about the upcoming changes and any feature requests you might have for Padloper 2. Whilst I cannot guarantee that any request will be implemented, I can promise that I will thoughtfully consider all feedback. Thanks for reading and thank you for supporting Padloper! kongondo

In this week’s post, we’ll take a look a look at the new website and focus on some parts of it and how they were built. Then we’ll dive into the latest version of ProcessWire on the dev branch, version 3.0.124— https://processwire.com/blog/posts/pw-3.0.124-and-new-site/

Here is my setup: My Dockerfile: # # PHP Dependencies # FROM composer:1.7 as vendor COPY web/ /app RUN composer install \ --ignore-platform-reqs \ --no-interaction \ --no-plugins \ --no-scripts \ --prefer-dist # # Frontend # FROM node:latest as frontend COPY --from=vendor /app /app WORKDIR /app/site/templates RUN npm install --global gulp-cli && \ npm --prefix /app/site/templates install gulp /app/site/templates && \ npm --prefix /app/site/templates install /app/site/templates && \ gulp build # # Application # FROM php:7.2.7-fpm-alpine COPY --from=frontend /app /var/www/html WORKDIR /var/www RUN apk add --update $PHPIZE_DEPS \ freetype-dev \ libjpeg-turbo-dev \ libpng-dev \ && docker-php-ext-install iconv pdo pdo_mysql mysqli opcache zip \ && docker-php-ext-configure gd --with-freetype-dir=/usr/include/ --with-jpeg-dir=/usr/include/ \ && docker-php-ext-install gd \ && rm -rf /var/cache/apk/* \ && chown -R www-data:www-data . # set recommended PHP.ini settings # see https://secure.php.net/manual/en/opcache.installation.php RUN { \ echo 'opcache.memory_consumption=128'; \ echo 'opcache.interned_strings_buffer=8'; \ echo 'opcache.max_accelerated_files=4000'; \ echo 'opcache.revalidate_freq=2'; \ echo 'opcache.fast_shutdown=1'; \ echo 'opcache.enable_cli=1'; \ } > /usr/local/etc/php/conf.d/opcache-recommended.ini \ My dev_docker-compose.yml: version: '3' services: web: image: nginx:alpine volumes: - ./etc/nginx/default.conf:/etc/nginx/conf.d/default.conf:delegated - ./etc/ssl:/etc/ssl:delegated - ./web:/var/www/html:delegated - ./etc/nginx/default.template.conf:/etc/nginx/conf.d/default.template:delegated - ./logs/nginx/:/var/log/nginx:cached ports: - "8000:80" - "3000:443" environment: - NGINX_HOST=${NGINX_HOST} command: /bin/sh -c "envsubst '$$NGINX_HOST' < /etc/nginx/conf.d/default.template > /etc/nginx/conf.d/default.conf && nginx -g 'daemon off;'" restart: always depends_on: - php - mysqldb php: build: ./ image: app:latest restart: always environment: MYSQL_HOST: ${MARIADB_HOST} MYSQL_PORT: 3306 MYSQL_DATABASE: ${MARIADB_DATABASE} MYSQL_USER: ${MARIADB_USER} MYSQL_PASSWORD: ${MARIADB_PASSWORD} volumes: - ./etc/php/php.ini:/usr/local/etc/php/conf.d/php.ini - ./web:/var/www/html:delegated - ./assets:/var/www/html/site/assets:delegated composer: image: "composer" volumes: - ./web:/app command: install --ignore-platform-reqs myadmin: image: phpmyadmin/phpmyadmin container_name: phpmyadmin ports: - "8080:80" environment: - PMA_ARBITRARY=1 - PMA_HOST=${MARIADB_HOST} restart: always depends_on: - mysqldb mysqldb: image: mariadb:${MARIADB_VERSION} container_name: ${MARIADB_HOST} restart: always env_file: - ".env" environment: - MYSQL_DATABASE=${MARIADB_DATABASE} - MYSQL_ROOT_PASSWORD=${MARIADB_ROOT_PASSWORD} - MYSQL_USER=${MARIADB_USER} - MYSQL_PASSWORD=${MARIADB_PASSWORD} ports: - "8989:3306" volumes: - ./data/db/mysql:/var/lib/mysql:delegated my prod_docker-compose.yml version: '3' services: web: image: nginx:alpine volumes: - ./etc/nginx/default.conf:/etc/nginx/conf.d/default.conf - ./etc/ssl:/etc/ssl - ./etc/nginx/default.template.conf:/etc/nginx/conf.d/default.template - ./logs/nginx/:/var/log/nginx - webroot-volume:/var/www/html ports: - "80:80" - "443:443" environment: - NGINX_HOST=${NGINX_HOST} command: /bin/sh -c "envsubst '$$NGINX_HOST' < /etc/nginx/conf.d/default.template > /etc/nginx/conf.d/default.conf && nginx -g 'daemon off;'" restart: always depends_on: - php - mysqldb php: image: app:latest restart: always environment: MYSQL_HOST: ${MARIADB_HOST} MYSQL_PORT: 3306 MYSQL_DATABASE: ${MARIADB_DATABASE} MYSQL_USER: ${MARIADB_USER} MYSQL_PASSWORD: ${MARIADB_PASSWORD} volumes: - webroot-volume:/var/www/html - ./assets:/var/www/html/site/assets mysqldb: image: mariadb:${MARIADB_VERSION} container_name: ${MARIADB_HOST} restart: always env_file: - ".env" environment: - MYSQL_DATABASE=${MARIADB_DATABASE} - MYSQL_ROOT_PASSWORD=${MARIADB_ROOT_PASSWORD} - MYSQL_USER=${MARIADB_USER} - MYSQL_PASSWORD=${MARIADB_PASSWORD} volumes: - ./data/db/mysql:/var/lib/mysql volumes: webroot-volume:

Check your /site/config.php file. There is a $config->userAuthSalt salt value present there and it would need to be identical between the two installations, otherwise the two installations are hashing passwords differently. That's usually a good thing, but in your case where you want the existing logins to work, you would want to keep that userAuthSalt value.

Just wanted to let you guys know that I've just released my new module that we've discussed here:

Hi @bernhard, that's a possible solution: adding a hidden field to that template and on saveReady concatenate all four field values into it. (Thats exactly what fieldtype concatenate does, if I rememeber correct). So, it sounds a bit quick & dirty, but then I can present one input field in the filter tab and show in the results the original single fields. Thanks!

Thanks for your help. I'll start over and be careful with database.

Thank you, sir.

@Robin S The download versions should be showing now.

I think this is the issue (HTTPS would pass through Apache port 443 as opposed to normal port 80). Could you try and disable HTTPS for admin login and see if it works? Since you cannot login, you can either do this on a fresh install or you will have to edit the home template entry in the database. Do you have access to the database? Is the frontend serving HTTPS content OK?

This part sounds somewhat curious. HTTP 1.1 request to /processwire (seems to work), then HTTP 2.0 request to /processwire/login (doesn't work) – is it possible that the server is not properly configured to handle HTTP/2? What happens if you directly request /processwire/login/, i.e. type it to the address bar instead of /processwire/? Also, just to clarify: when you enter /processwire/ you get the error for /processwire/login/ right away? You didn't even see the inputs for username and password? If so, it might also be that there's something in the site or browser cache that breaks things. If your site is using default session management, i.e. files on the disk, you could start by clearing /site/assets/sessions/ of any session files currently in there. Also make sure that there's nothing odd in your browser cache by clearing that as well, or opening the admin in an incognito tab or something similar. If you've enabled database sessions, you'd probably have to clear them manually from the related database table (haven't used this feature, so not sure how exactly). By the way, the certificate error doesn't sound too good either. Did you have a certificate set up on the old server, and can you set up one on the new one as well? Although this seems unlikely, one possibility is that the server isn't properly serving HTTPS content. This is somewhat off-topic, but it seems really strange that a hosting company (assuming that this is the case) moves the site to a new server without informing you, and without providing proper support, or even making sure that things work as expected after the move. When that kind of thing happens, you might be better off looking for a new hosting provider. Just saying.

Multiple sites are possible with Laragon, but if you use the same database in your site/config.php, well you have the same data in both installations.

I guess nvim is earning money in other ways... Still can't understand why nothing is done...

I'm a TotalFinder user which is not a replacement but an "extension" injecting runtime mods into the Finder. It's "used-to-be free" alternative is XtraFinder which I also used for years but was a bit too buggy to my taste so I switched to TotalFinder a few years ago which is more reliable. I use Yummy FTP Pro and Beyond Compare as well.

What is the exact error message? What do Apache error logs say? What is chrome/firefox showing in network tab? 403? Maybe temporarily set debug on in /site/config.php to see if you can get a better error message (I doubt though, since it seems this is stemming from a server mis-configuration and ProcessWire does not even come into play)

Yep, I've got profilerpro monitoring them and if any url gets more than a couple hits then I add a redirect. It looks like there were a few I missed but slowly accounting for them as they pop up.

Maybe Ryan can introduce pagination in the public API ? E.g.: ../exportjson?limit=10&start=350 This is not uncommon in high-traffic public APIs.

@adrian I am developing it as a module for now, but at a later point will replace ProcessModule with my code. For getting the JSON data I used code from Somas Module Manager, which seems to get only the 350 items you mentioned ? We have to think of a way, to get them in batches, or @ryan has to change the limit. I did not thought about the complications yet when the limit is higher. I got filtering working, but not in the way I want. Some things turn out to be more complicated than I thought. Anyways, here's a lil teaser for you guys ?

Hi all! Happy New Year ? I recently rebuilt the website for classroombookings - my open-source room booking system for schools - using PW ? classroombookings.com I started the project itself way back in about 2006, when I was working in a school and needed a solution. Over the years I haven't made that many changes to it - mostly due to lack of time - but it has a modest userbase. Fast-forward to late 2018 when it required a major update to support PHP 7, fix some issues, and I also launch a hosted service. The website serves marketing, documentation and download/release functions for the project and I think PW is ideal for it. In the spirit of open source, the code for the website is also available on GitHub for anyone who wants to poke around and see my approach to PW web builds. The site is pretty standard, the only 'custom' bit is the releases section, which it pulls from GitHub using their API and creates/updates pages (Releases module). The frontend uses the Spectre CSS framework, and this is the first site I've built using it. Modules: AdminTemplateColumns ProcessDateArchiver SettingsFactory TextformatterHannaCode

Great tool - when will you build it as a PW module....just kidding..;)

Hehe so much for not having much time ? Since you guys are a million miles faster than I am what I'll try to do today and tomorrow is an interface mockup for how I think it could look with categories and thus favourites idea so we've got a few ideas to pull from. In terms of instructions for modules - they're hit and miss as to whether they're on a GitHub readme.md file or entered into the Modules directory itself, but I think the code on the Modules directory can easily be tweaked to pull from either source. I also don't think that there are so many modules that if we thought there was some other essential functionality that was required (like something that HAD to be read before install) that there could easily be an extra field added to the DB to flag that up in a consistent manner. Sure there are a lot of modules, but for better or worse there are a lot of ways to store the config info too so maybe the Modules database itself is the only consistent way around that if we need to? Will post more later. Got to paint a kitchen first (yay ??)

@ryan, the new site search is great - such an improvement over the previous version. After searching I find myself trying to use the keyboard (arrow keys, enter) to highlight and select results, like I can in the PW admin search. Would it be possible to add this feature to the processwire.com search?

Hi, This is my another PW website - http://pkrosifoundation.org No Modules used

@manlio Have you deleted repeater fields with same names?

You're talking about wall-time. To be really save for future dates you need to store not only the datetime (UTC) + timezone, but also the wall time. There are changes in timezones multiple times per year and some are even countries changing how their timezones work. If you have both UTC and wall-time you can detect such changes and react accordingly. The UTC time you need as soon as you need to compare / act on times, which are in multiple timezones, you need to interact with some APIs or export .ics calendar files. So for your examples it might be fine to disregard the timezone and only use wall-time. Here's some more information on why timezones are hard: https://zachholman.com/talk/utc-is-enough-for-everyone-right I've also found this to be a good blog with a bit more actionable advice: http://www.creativedeletion.com/

$this->addHookAfter('ProcessTemplate::buildEditForm', function ($event) { $form = $event->return; $template = $event->arguments[0]; $icon_field = $form->find('name=pageLabelIcon')->first(); $icon_field->collapsed = Inputfield::collapsedHidden; $field = $this->modules->get('InputfieldText'); $field->attr('id+name', 'template_emoji'); $field->icon = 'list-ol'; $field->attr('value', $template->template_emoji); $field->columnWidth = 100; $form->insertAfter($field, $icon_field); $event->return = $form; }); $this->addHookBefore('ProcessTemplate::executeSave', function ($event) { $template = $this->templates->get($this->input->post->id); $template->set('template_emoji', $this->input->post->template_emoji); }); $this->addHookAfter('ProcessPageListRender::getPageLabel', function ($event) { $page = $event->arguments('page'); $template = $page->template; if($template->template_emoji) { $event->return = $template->template_emoji . ' ' . $event->return; } });

Thanks to those who noticed the 404 happening on the Jobs site. I've been on my Christmas break, hence the lack of response from me on the AAD Web Team forum account. We had some wider network issues going on which were out of the web team's hands, but the right people were aware of it and worked hard to get things going again. ?

Just released this language pack for the latest master 3.0.123 (only 3 days after release)

Thx Ivan, I was actually more interested in his/her/its response to my statement than in yours ? But yours is a very good one and shows the high quality of this community. Thx - I'm happy to be here and improve! Let's see what he/she/it found out about ecommerce with processwire so far - maybe he/she/it has some valuable information for us... ?