Leaderboard

Hey All, I thought I'd jump on here and share my first 3 ProcessWire sites! LatticeWork (https://www.latticeworkinc.com/) - This one is live but still being actively developed in preparation for targeting an international audience (so current translations need auditing and it's not yet GDPR-compliant). The multilingual capabilities offered by ProcessWire, in contrast to WordPress, were the catalyst for starting my PW journey. The added performance that will be necessary as we deprecate some international sites and push everyone here was another decision driver for choosing PW. Obviously many thanks to @ryan and other core contributors for such an incredibly refined core product that regularly surprises me with features and functionality that I didn't know I was missing. Additional thanks go to @FireWire for the Fluency add-on, @Mike Rockett for Jumplinks, @Wanze for SEO Maestro, @teppo for Search Engine, and again Ryan for Pro Fields. These were invaluable. The Mart Group (https://www.martgroup.com/) - This site was my second to build with ProcessWire, though it was completed first due to its smaller size. In addition to all the prior thanks, I really appreciated RockFrontend by @bernhard while working on this one. Lori H. Cole (https://www.editsbylori.com/) - I probably wouldn't mention this single-page site I built as a favor, except to point out that PW is so lean and easy to work with I was able to give the client the ability to edit their own site without much server overhead or added development time. I did the front-end development work on these, which as a designer/animator hasn't historically been an area I'm comfortable in. ProcessWire has been such a delight to use that it has re-kindled my interest in working more with code. So, in time I hope to get more creative with the front-end coding as well. Thanks!

Like last week, this week the focus has been on adding feature requests from our processwire-requests repository. Though I'd like to give it another week before bumping up the version number. Rather than repeating all that was added here, please see the dev branch commit log, which covers them all, several with more detailed notes in the commits. The biggest added feature request was likely the API updates for getting/setting multi-language values, but there are several others as well. I was excited to see the new jQuery 4.0.0 release this week, which we'll no doubt be upgrading soon (or once out of beta). Here's a quote from the intro of their new post: Some parts of ProcessWire's API were originally inspired by jQuery. It's always nice to see progress there with new versions, especially a new major version. Thanks for reading and have a great weekend!

If you're not using Ddev as your development environment, you should definitely consider it. I'm astonished at the speed and flexibility. Up till now I'd been using WAMP which, for it's time was a great all round solution but the speed was abysmal, even for a local server. I looked around and found ddev. Here's how to find it: https://ddev.com/get-started/ A few strange things / notes - at least to me, this isn't my full-time job, I'm a photographer who was a dev of sorts for a while: The database host isn't "localhost" it's db, yes, instead of putting localhost as your host, you put db. So if you have connection errors that's most likely why. On windows, you can access your files through: - Explorer - look for the Linux icon - You can also access them through a network share, I forget exactly what that is. You can transfer existing files / projects for windows into the VM via explorer. For VS Code windows there is a WSL plugin, this allows you to work directly on the files inside the Linux VM / container Don't store your files inside windows, as in outside the VM. It's not required and slows everything down, or so I've read. The first project you run downloads everything needed for ddev so it'll take a while. After that, it's quick. If importing a db via ddev, it doesn't seem to give a progress or errors. - I had the "COLLATE" error inside my dump. The import stopped when it reached that table with no error output or warning, I had no idea. - I like phpMyAdmin and imported through that which gave me an error of the issue therefore allowing me to solve it. WSL or windows subsystem layer is a lightweight VM manager, as I understand it. - You can run multiple Linux distros through it. - It integrates the distro really nicely with windows. Lastly, the speed! Omg the speed! I get impatient waiting for reloads when I've changed code. Ddev is blazing fast! I hope this helps someone else who might have some of the same questions I did. Have a great weekend.

As of today on the dev branch, this is now possible with a new hookable method InputfieldPage::renderPageLabel() https://github.com/processwire/processwire-requests/issues/460

Looks like now is a great time to dive back in!

https://processwire.com/blog/posts/new-rte-for-pw/ (see Toolbar configuration) https://processwire.com/blog/posts/using-tinymce-6-in-processwire/

Look at this idea: Since I have been using this method, I no longer need any other approach to build up the content on my pages and I also need far fewer different templates. You don't have to use depth, but it allows extremely flexible output of content when needed. My basic_page template look like this: <?php namespace ProcessWire; include "_header.php"; $items = $page->content; foreach ($items as $key => $item) { $item->position = $key; $item->all_items = $items; } foreach ($items->find("depth=0") as $item) { echo $item->render(); } include "_footer.php"; And all matrix "content" templates are inside the fields folder.

Glad you found it and thanks for the tips for windows users. There is a dedicated forum thread with tips & tricks:

I found the problem, unless I missed something, it's not obvious. The host in ddev is "db" not localhost DBname: db DBuser: root or db DBpass: root or db DBhost: db DBport: 3306 Hopefully, this saves someone some Internet Scouring time. ?

This tutorial might help? https://processwire.com/talk/topic/27499-something-like-gutenbergdrupal-paragraphs/#comment-226306

View at: https://okeowoaderemi.com I switched to Processwire 10 years ago and it's being my goto framework for maintaining my website and also developing for clients. Development I used the moduleTemplateEngineFactory and TemplateEngineTwig, Twig has always been my favourite templating engine, because of how easy it is, to use reusable code and have an easy way to inject content into the layout, it's almost like MasterPages in .NET (For the Oldies)

FieldtypeGrapick The FieldtypeGrapick module for ProcessWire wraps the Grapick vanilla javascript gradient creation UI and extends the feature set to include settings beyond what the original library allowed for. The original javascript library was written by Artur Arseniev. Aside from requiring ProcessWire 3, the requirements are: PHP >= 7.2 or >= PHP 8.0 This module makes use of the Spectrum colorpicker library. Repeater and RepeaterMatrix items are supported. There is a gremlin in RepeaterPageArray iteration that causes warnings. I've created an issue for it. It does not impact performance. CssGradient Object The FieldtypeGrapick field value is a CssGradient object. $gradient = new CssGradient( $options=[] ); where $options is a list of properties: $options = [ 'style' => 'linear', 'stops' => 'FFFFFFFF^0|FF000000^100', 'angle' => '180', 'origin' => '', 'size' => '', ]; Properties The CssGradient style by default is linear, 180deg, with a white opaque stop at 0% and a black opaque stop at 100%. style $gradient->style: gives you the dropdown value of the style of gradient. Setting this automatically uses the correct settings for the css function and shape parameter as required. Possible values: 'linear' = Linear 'radial-circle' = Radial Circle 'radial-ellipse' = Radial Ellipse 'repeating-linear' = Repeating Linear 'repeating-radial-circle' = Repeating Circle 'repeating-radial-ellipse' = Repeating Ellipse 'conical' = Conical 'repeating-conical' = Repeating Conical Any other value defaults to linear. Depending on the type of gradient selected, origin, angle, and/or size will come into play. The stops are always used to determine the order of colors and their relative locations according to the limitations of each style. origin $gradient->origin: gives you the dropdown value of the origin of the gradient as it applies to radial and conical gradients. The format is X%_Y% if for some reason you want to set a custom X/Y origin. The dropdown values are typically what I find useful for most applications, but I am open to adding other presets. '-100%_-100%' = Far Top Left '50%_-100%' = Far Top Center '200%_-100%' = Far Top Right '-50%_-50%' = Near Top Left '50%_-50%' = Near Top Center '150%_-50%' = Near Top Right 'top_left' = Top Left 'top_center' = Top Center 'top_right' = Top Right '-100%_50%' = Far Middle Left '-50%_50%' = Near Middle Left 'center_left' = Middle Left 'center_center' = Center 'center_right' = Middle Right '150%_50%' = Near Middle Right '200%_50%' = Far Middle Right 'bottom_left' = Bottom Left 'bottom_center' = Bottom Center 'bottom_right' = Bottom Right '-50%_150%' = Near Bottom Left '50%_150%' = Near Bottom Center '150%_150%' = Near Bottom Right '-100%_200%' = Far Bottom Left '50%_200%' = Far Bottom Center '200%_200%' = Far Bottom Right angle $gradient->angle: gives you the angle in degrees of the gradient as it applies to conical and linear gradients. Should be a value between -360 and 360. Measured in degrees. size $gradient->size: gives you the size - of what depends on the type of gradient. For radial ellipse gradients, at applies a size of XX% YY% using the value. So 25 would represent a size of 25% width, 25% height of the container. For repeating linear, conical and radial gradients, the repeating gradient will apply the percentage stops as a percentage of this value. In the case of repeating linear gradients, if you have your stops at 0%, 10%, 50% and 100% and your size is 200, the stops in the calculated rule will be at 0px, 20px, 100px and 200px. For repeating ellipse and conical gradients, a similar calculation is performed, but the units are %, not px. You can get some crazy tartan backgrounds out of this if you stack your gradients up and are creative with transparencies. stops $gradient->stops: gives you the current stop settings in a AARRGGBB^%% format, with each stop separated by a '|' character on a single line. You can role your own gradient ruleset by modiying this property prior to getting the rule. When using the UI you can also reveal the Stops inputfield and change the stops manually, however you will need to save to see the changes in the UI. rule $gradient->rule: gives you the stored rule that is calculated prior to the field value being saved to the database from the UI. Of course, if you are ignoring the UI altogether and just using the class, you will probably ALWAYS want to call getRule() rather than use this property. If you render the field, it will return the rule as a string. Methods The CssGradient has a single public method that is mostly useful when manipulating an instance of the CssGradient class. getRule(string $delimiter) $gradient->getRule(): calculates the rule based on the properties or options you have set for the field. This automatically runs if you have set an $options array and populate the rule property, but if you decide later that you need to change the properties of the object, you'll want to manually call it again to recalculate it. For example, if you programmatically change the stops, you will want to run the getRule() method rather than just grab the rule property. If you pass a string, the first character will be used as an ending delimiter. If you pass an empty string, no ending delimited will appear. By default, the rule is output with a semicolon. Grapick UI The Grapick UI is relatively straightforward. Clicking the (x) handle above a gradient stop removes the stop from the gradient calculation. If you remove all the stops, the bar is transparent. Clicking on the gradient bar sets a stop conveniently set to the color you click on. Clicking on the colorpicker box below the stop line allows you to select the color and transparency of the stop. Click and drag the stop line itself to modify the gradient. Making changes to any of the controls on the field will update the preview and the calculated rule in real-time. You can always cut and paste this rule and use it in your designs elsewhere if you want. Likewise, if you open the Stops inputfield area (which is collapsed by default) you can directly alter the colors and code using a color in an AARRGGBB format and adjust the stop with a number from 0-100. It's fun to play with - experiment with hard and soft lines, size and origin - many interesting effects are possible. Do not forget that the alpha slider is also available. Examples $grk = new CssGradient($options=[ 'style' => 'linear', 'origin' => '', 'angle' => 270, 'stops' => 'FF8345E4^0|FF5A08DB^25|FF2C046B^97|FF000000^100', 'size' => '', ]); echo $grk->getRule(); will give you: linear-gradient(270deg, rgba(131, 69, 228, 1) 0%, rgba(90, 8, 219, 1) 25%, rgba(44, 4, 107, 1) 97%, rgba(0, 0, 0, 1) 100%); while echo $grk->getRule(''); will give you linear-gradient(270deg, rgba(131, 69, 228, 1) 0%, rgba(90, 8, 219, 1) 25%, rgba(44, 4, 107, 1) 97%, rgba(0, 0, 0, 1) 100%) and echo $grk->gerRule(','); will give you linear-gradient(270deg, rgba(131, 69, 228, 1) 0%, rgba(90, 8, 219, 1) 25%, rgba(44, 4, 107, 1) 97%, rgba(0, 0, 0, 1) 100%),

@Pete TinyMCE version is available but i have discovered a few bugs:

Nice work as always. I upgraded 2 sites in development this week to jQuery 4 and everything worked just fine. Scripts we had made, Swiper, Splide, Fancybox and a few other go to scripts all worked fine. I think it's about 10% lighter as well, maybe more which is always welcome. Nice to see one of my request hit the commits. Have a great weekend.

@ryangorley Nice work, great sites! Would you consider adding them to the sites directory? https://processwire.com/sites/submit/

Thanks @wbmnfktr! Yes, these are using ProCache. I forgot to mention that one, though I worked very hard to ensure uncached pages would be fast upon first visit, which I'm very satisfied with ProcessWire they are.

Thank you for letting me know! I did so much Google searching and didn't realise there was a forum thread in my favourite place.

You can access it directly and get a JSON response, when the path is correct: {"error":"FLUENCY_METHOD_NOT_ALLOWED","message":"Fluency API Error: Method Not Allowed"} But I didn't get anything so I looked closer to the path and saw that I had a wrong path. I had /processwire/fluency-1/api/translation/ as api-path, which was probably due that I deleted the module and reinstalled it so maybe it created this new path. I changed it now and it works. Second: Still when I try to edit the settings page in the Module I get the 503. See the attached network response. I still think it is somehow a security issue, when trying to save to the database due to all this serialized data in the POST-request. DB is by the way MySQL 8.0.

If you want a solid solution that has seen several years of development and is tailored exactly towards that use case have a look at RockPageBuilder: It will not only make your life as a developer easier, it will also tremendously improve the editing experience for your clients. Try it out yourself at https://pagebuilder.baumrock.com

Code here: and here: might be helpful. This implementation is working for me on several projects.

FWIW -- I have a template called "downloads". When someone goes to https://example.com/downloads/specialfilename.php, the file name is treated as a url segment. From the url segment, I will essentially: Search for the file Make sure it's there Then deliver it via the mime process // Get page ($p) where the file lives // Still here, so lets see if we can get the actual file $file = $p->filesManager->getFile($fileNameSanitized); if(!$file) return 'File not found(3)'; header("Content-Type: application/pdf"); header("Content-Disposition: inline; filename=$fileName"); header("Content-Transfer-Encoding: binary"); header("Accept-Ranges: bytes"); @readfile($file->filename); return true;

Hi @Mats i had been fighting for a while with this too and ended wrting my own solution to keep some hair on my head ? and my pleasure of course have a nice day

Why using JS and not a saveReady hook? And maybe a hook on ProcessPageEdit::processInput(form:InputFieldWrapper) to check that fields content is valid and mark them as "error" in the form. You can also manage errors in saveReady by displaying an error Notice to user.

Have you tried the template settings for file-level access control? It might not be exactly what you want (without some fiddling), but it's what currently seems the closest thing to what you're looking for.

This fieldtype has been released and is awaiting approval. I changed the angle input to be an integer entry. I did pull together a strategy for building instances within repeaters. I'll do a writeup of the design pattern as a brief tutorial, as I think until we have a proper set of event handlers for repeater actions/AJAX etc. this is a way to build out a field that requires javascript libraries that is repeater compatible. I feel pretty happy with the end result. It is a fun toy to play with if you have never really explored CSS gradients.

I feel like this is getting very close to a release. The 'Stops' area is the primary data section of the field. If you want to create your own gradient color/stop combos by entering them here you can. AARRGGBB^0-100 is the format with pipes in between. The spectrum color picker is used in the builder. I haven't figured out how to get showIf to work with fields in this context, but the rules will only apply values that make sense with regard to the type of gradient you wish to build. I did include repeating linear and ellipse. I realized at the end I completely overlooked conical, but I know it is getting more use in gradient border button application techniques so I will add it. The repeating method takes your stops, divides them by 100 and multiplies them by the number you put in for size. If you don't put in a number, it defaults to 100px. There are many ways to declare the size of repeating patterns, but this seemed to make the most out of the Grapick format. Everything updates in realtime as you make changes. Might be less intensive ways to do that - I'm looking into it. As a standalone it works, I need to review some of the notes people have made about context and do some testing in repeaters before I release it. I have set up the client-side stuff to accomodate multiple isntances of the builder on a pageedit form, but I'd like to do a little more testing to make sure everything saves properly. I also want to make sure the API works as expected - e.g. if you use the API to set the stops portion can you get the rule out and so on.

The fun, and not-so-fun (in this regard) thing about ProcessWire is that it gives a lot of control over how to use it to the developer(s) creating the website(s) with it. It's a CMS/F (Content Management System/Framework). The reason I state this is because doing what you did, depending on how the original developer handled things, could work. Typically though, when you create a field, you then add that field to a template (or multiple templates) you wish to use it in, and then with the page(s) that are assigned that template, you reference it from within the PHP code of the template file(s). There are ways to create globally accessible fields so that it will always be accessible to editing from the interactive administrative back-end, but with something unlikely to be changed by a standard end-user (such as a Google Analytics script), you should be able to just edit the template files directly, and hopefully the prior developer made it easy enough to identify which file contains the code for the standard HTML headers. There are some confusing jargon when you're just getting started with ProcessWire: Templates, and Pages There are "template files" and "[system] templates". ...and "pages" in ProcessWire are essentially units of storage, since nearly everything is a page within the system, essentially a custom-named object that docs refer to. So you create a "page" and usually refer to "$page" objects, but $page objects can have fields (properties that hold values) that are also $page objects. ? Here's a good place to start: https://processwire.com/docs/tutorials/hello-worlds/ If you'd prefer a video walkthrough, although it's a bit advanced, it's recent and does also go through the basics.

Happy to announce the launch of the completely rebuilt San Francisco Contemporary Music Players website, using ProcessWire. https://sfcmp.org/ The previous website was a hornet's nest of disorganized content, dozens of 3rd party plugins, duct taped together within WordPress... difficult to use, time consuming and confusing to manage. And didn't look so good either. Lot of fun to rebuild this, though took several months. YOOtheme Pro and UiKit were a dream for me to work with, just love those. Made it so possible to create all of the custom sections, widgets, sliders, cards, mega menus, and so on. Don't consider myself a front-end focused web dev, so have a deep appreciation for the time, care and effort that Yoo has put into both UiKit and YOOtheme Pro. Almost no additonal CSS was needed to be written for this; the stock UiKit classes and attributes make it possible to just build things in HTML and not have to fiddle with CSS. Ryan's commercial modules played a major role in the build. ProFields, ListerPro, ProCache, and FormBuilder were all important. FormBuilder+Stripe allowed me to confidently migrate their need for a stripe checkout from some WP plugin to the clean and simple setup now using FB. ( https://sfcmp.org/donate/print-for-sale-dirge-by-hung-liu/ ) Some libraries also were of great use and value, namely PLYR for audio, and tabulator for some table display type of stuff. As always, the API was a dream to work with, many custom import scripts were created along the way to import legacy Press, Albums, Repertoire works, Program Booklets library, Players etc.. The image API is doing wonders with SRC sets, and webp images. The PW documentation site was a daily companion. This forum likewise was always a most valuable and enjoyable resource to search and rely on for solving the occasional conundrum. There is such a wealth of info here that i never found it necessary to post a question. Lastly, to underscore just how unparalleled, flexible and user-friendly the PW backend is, we had the backend training session a couple of weeks after the site was launched, and within 30 minutes, the person who will be managing the content was able to know how to create and manage concerts, blog posts, albums, press articles and more.

HannaCodeDialogTiny is now in the module directory.

Ok so here's what worked for me for now to develop composer packages locally while having them working in a ddev project: Add a volume to the web service on ddev adding file .dev/docker-compose.composer-packages.yaml: services: web: volumes: - "${COMPOSER_PACKAGE_DIRECTORY}:/packages" I've also heard it's advised to add this as a whole other service? Let me know if anyone thinks this is better! You can then define whatever path on your file system in .ddev/.env such as: COMPOSER_PACKAGE_DIRECTORY="../../packages" Now you could just git clone you repos into the path you defined in the variable and "ddev composer install" in case you have the following configuration on your composer.json and it will symlink your libraries instead of { "repositories": [ { "type": "path", "url": "/packages/*", "options": { "symlink": true } } ], } Check the url matches the target the container's path in the volume definition made in the yaml file. I added the additional layer to this proposed by the original article that put me to work, to be able to have my composer.json "clean" and without the local package path definition. I setup the script adviced in the original article: #!/usr/bin/env bash command -v jq >/dev/null 2>&1 || { echo >&2 "jq is required to support local development of composer packages, please install using your OS package manager before continuing"; exit 1; } jq -s ".[0] * .[1]" composer.json composer.local.json > composer.dev.json COMPOSER=composer.dev.json php /usr/local/bin/composer "$@" rm composer.dev.json [ -e "composer.dev.lock" ] && rm composer.dev.lock Save this as .ddev/commands/web/composer-local Create a composer.local.json where you can hold a local configuration that will be merged with composer.json into a temporary composer.dev.json file that will install this merged combination, guarding your composer.local and composer.lock file from being edited. Example I am using as composer.local.json: { "repositories": [ { "type": "path", "url": "/packages/*", "options": { "symlink": true } } ] } If you comment the lines that delete the composer.dev.json you'll see that the property "repositories" value is overwritten by our custom definition. Then run: ddev composer-local install You should see your composer dependencies available as local packages linked to the repository. You can just roll back with the regular composer install: ddev composer install I am still unaware if deleting the composer.dev.json and .lock files are really necessary as it did help me figure out what was going on. Please test if you find this useful and let me know how it goes. Thanks everyone for your thoughts and work put into this thread, I'm really enjoying migrating to ddev!