Leaderboard

Hi Jeevanish, For the most point some of these are just buzz words. Headless CMS is basically the CMS exists away from the website and talks via an API such as JSON / XML / GraphQL (This allows you to use the data anywhere on the web or an internet connected drive, lets say for an APP) Hybrid CMS is something that seems relatively new, and it seems to be that Headless CMS doesn't have great editor functionality, hybrid seems to be a buzz word around it's a great easy to use CMS with Headless functionality, I guess if you installed GraphQL to ProcessWire it would be considered hybrid. Digital Experience Platform seems to be a platform that all talks to each other using different mediums. Lets say you have a train station, that system lets you book a ticket, that then updates a message board letting them know how many tickets are left, which updates their website and also sends to the ticket attendents which shows that the ticket is for that train. This is just an example. This system can be accomplished with Headless or Hybrid.

And there is a matching "field-admin" permission as well: https://github.com/processwire/processwire/blob/649d2569abc10bac43e98ca98db474dd3d6603ca/wire/modules/Process/ProcessField/ProcessField.module#L53

Hi @ryan, This is indeed an ingenious little helper! Thx for sharing this idea with us! One problem though: When I'm only in the backend, the url and filename methods get never called. Could you please make the setFilename method hookable so that this method also works when the page is just edited in the backend? It would then only need this simple hook and all files are downloaded on demand: $wire->addHookAfter('Pagefile::setFilename', function($event) { $file = $event->object->filename(); if(!file_exists($file)) { // download file from source if it doesn't exist here $src = 'https://example.com/site/assets/files/'; $url = str_replace($this->config->paths->files, $src, $file); $http = new WireHttp(); $http->download($url, $file); } }); Or is there a better way of doing it? Edit: Ryans version does of course work without issues - just make sure to have the proper PW version installed ^^

Don't think I've ever used this, but according to the ProcessTemplate core module the template part should be possible if you create a new "template-admin" permission and assign it to any non-superuser role. Based on a quick test it seems to work. ProcessField supports similar "field-admin" permission, which might give you the expected result regarding fields. This does seem like a rather unlikely need, so I'd first check if this is really what you want. Certain tasks are limited to superusers for a good reason ?

You will need: ProcessWire (of course) ProcessWire ProCache ProcessWire Modules as you like and need Netlify Account (in my case, you can use any other hosting or Github pages) Git Account (Gihub, Gitlab, Bitbucket) ScreamingFrog (free version should fit most needs) Things to keep in mind FormBuilder will not work (out of the box) 40x/50x must be defined separately Redirects must be defined separately Module-based functionality will not work GDPR/Opt-in/Cookie consent must be added differently Avoid using core/module files (UIKIT, jQuery, CSS, etc.) Where to save files and how to address them Most content and design related files can be saved in ProcessWire itself. Logos, favicon, trust icons and whatsoever. Some files can't be stored in ProcessWire - or shouldn't be stored in it - fonts and sitemaps (XML) in my case. While developing the overall site always use relative paths and URLs. Fonts and other assets need to be addressed by their web-root-based path (/site/templates/myassets/font.ttf and so on). Internal linking should be relative as well. Otherwise you have to change those link URLs manually which is PITA. Which files to copy and where you find them As we use ProcessWire we want and should use everything we can to make our webdev life easier here. Let ProcessWire and some modules do the work while harvesting the results for our benefits. While ProCache takes care of generating minified CSS and JS, SEO Maestro generates a nice and handy sitemap.xml. Depending of your installed modules you want to (at least) double check the output and results in your static site. As already mentioned FormBuilder and Simple Contact Form will not work, 404 management and redirects by the awesome Jumplinks modules will not work, too. Instead you have to create your very own .htaccess file with all redirects and error documents. Other modules like MenuBuilder, SEO Maestro and some other modules do a pretty good job even in your static site as their benefits result in already rendered HTML/pages. Autolinks, Automatically link page titles and Share buttons are some modules that will work as well. While it didn't work for me it may work for you - the Cookie Management Banner module. I had some issues and decided to install and use Cookie Consent manually. The Workflow First of all build your site. Make it perfect. Do whatever you or the client wants or needs. Whenever possible look into your rendered HTML and cached pages. Take a closer look at all the URLs and paths. It's already a good idea to run ScreamingFrog and find out if there are any files missing, links broken or pages missing. When everything is done, clear all cached files, all minified JS and CSS. Start a ScreamingFrog session and let it run. It will visit each and every page on your site it can find. Hidden pages, orphaned pages and of course drafts and pages behind JS-links will not be found and therefore cached by ProCache. Look into /site/assets/ProCache-XXX/ and /site/assets/pwpc/ now and double check that there are your pages and JS/CSS files. You will need those afterwards. If everything is fine you have to copy things around now. The Setup - folders and structure In my case the easiest way to go was setting up two local sites - one with ProcessWire and another one with the static files, assets and other things I needed. In the examples below only relevant parts are listed. project.pw.test (ProcessWire) /sitemap.xml (Generated by SEO Maestro) /site/assets/files/ (copy the whole path) /site/assets/pwpc/ (copy the whole path) /site/assets/ProCache-XXX/* (copy only the content of this folder - all files and folders) /site/templates/myassets/ (copy the whole path) project.sv.test (Static version) .htaccess (for redirects and 40x/50x error pages) 40x.html 50x.html /sitemap.xml /site/assets/files/ /site/assets/pwpc/ /site/templates/myassets/ all files and folders from /site/assets/ProCache-XXX/ As you can see there are only a few things to copy. When you're done with copying these files to the static version of your project, open it up in your browser. Check for missing files and test it. Let ScreamingFrog do the most work and check for any kinds of errors. Fix them in your ProcessWire-site and copy and test again. Check your 404s, your redirects and everything else you would normaly test. Create checkafterupdate.txt and write down whatever went wrong in your first try. This will be a great checklist later. The Final Step As everything is copied now and at its correct place you can upload it to your host. In my case the static version is a private git repository on github.com. I can commit and push my changes there and Netlify takes care of publishing the new version - most of the time within seconds. The benefit of using git - compared to S/FTP - you always have some kind of control if something brakes and you have to revert and check changes. In my case it's Netlify but you can use Github pages or any other hosting solution you want/the client pays for. Be careful with GDPR-related things as DPAs. You have to have them in most cases - Netlify did a great job here and I found everything I needed, while Github disqualified itself back then due to missing documents and kind of a sluggish support. Questions? Ask.

There are two parts to this. Connection to a database and SQL features/parity in results. Connection to the db is abstracted through PDO and most things in processwire use the PDO powered database connection. In old code you might still find things calling to the old mysqli powered processwire class. The part about sql features and their parity in implementation/results is another topic, which requires a good amount of knowledge of both databases. Actually PWs query engine isn't really using many fancy sql features, most stuff is just many joins + conditions, but I don't know sqlite well enough to evaluate if everything will be working there as well.

Yeah, edited my message as well. Didn't read the original question properly, thought it was only about templates. Just gave these both a try and so far they seem to work – though this is a rare use case, so wouldn't be entirely surprised if there were some gotchas along the way ?

Hi Everyone, First of all, a big thank you to the Processwire team. Ever since I started using PW I never used anything else, or took any job where I would not be allowed to use it if I deemed it the best tool for that job. It has allowed me to create demo forms and presentation screens live on the spot during negotiations and training sessions, which sometimes can have a great effect. It has also allowed me to reach interesting people with the open source message. But I do have a question. Is it possible to have a none-superuser (can't manage superusers), but who can create fields and templates?. It seems to me now that only superusers can create fields and templates. As with most things in Processwire, I have a feeling the solution will be one easy switch somewhere, but I just can't find it.

Hi Robin, Thanks for making this module. Just wanted to let you know that I ran into an error when I tried to export a repeater field: Let me know if I can provide any other information.

Glad you found it yourself. What's also possible is to just add a page-{name} or page-{id} to the item template and use them to style.

Thank you @Robin S! That was it.

Okay, I see where you are going wrong. You need to enable pagination for the template that is listing the results, not for the template of pages you are getting in your find() selector.

If you try to create some sort of page-builder featureset this way, than this is not what you are looking for as fields and templates are for developers (and most of the time they are the only superusers in the system...). People usually use RepeaterMatrix or sometimes the PageTree to implement page-building functionalities. There are plenty of examples in the forum demonstrating these. Some devs used custom coding too, again, they showcased their work in the forums.

OK, I've found it out myself now. The trick is to make the field accessible by API. Then you can simply write something like: function getRestrictedProperty($page, $fieldname, $user) { $field = $page->getFields()->get($fieldname); if ($field == null) return ''; return $field->viewable($page, $user) ? $page->get($fieldname) : ''; }

I use an IDE and found it stressful to have to work-around deploying config.php This is how I found your thread. Thank you! I integrated your solution into my own workflow and came up with this to share back here: /site/config.php (like @bernhard except last line) // include config file from outside of the repo $client = 'config-' . end(explode('/',__FILE__, -2)); include("../$client.php"); The PHP end() function and the minus 2 in the explode(), always gets the URI domain base. (As long as PW keeps it there.) Since my usual deployment flow is from ABC.dev -> test.mybox.com/ABC -> ABC.com ...in my root folder, safely out of reach (like @bernhard's concept), I then create 3 files each containing config deployment differences. ../config-ABC.dev.php and ../config-ABC.php and ../config-ABC.com.php For those also using PHPStorm, since these files are located out of project, I would add them in Favorites. (And add it's root folders in Deployment Mappings). I can then easily make use of IDE features like "Compare Two Files", "Sync with Deployed to", etc. Removing doubts about what config property I may have missed across the board. No more stress.

super user.s required to create fielders y templatos purposefulness of super user this.is with out such purpose is not.super

What you're seeing there is just what happens between browser and server, i.e. spaces getting replaced by %20. If you're echoing the value, it won't get executed as PHP code (you'd have to call eval or something similar to get that effect), but it could still allow HTML or JavaScript through – which is probably also something you don't want to allow. For an example, see what happens if you set the key value as <script>alert("hi")</script> instead. The general rule of thumb is to always sanitize user input ? That being said, if you're certain that you're only reading the GET variable and comparing it to some pre-defined value, and you'll never store or output it as-is, then there's no real harm in not sanitizing it. As you've proven yourself, it won't get evaluated as PHP code.

AdminBar 2.0.1 released: Plenty of updates behind the scenes. So far "end user" functionality remains largely the same, though. New options for hooking – decent support for modifying generated output and adding all-new links and other features programmatically. Extended theming support: the module now comes with three built-in themes ("original", "tires" per the theme submitted earlier by @tires, and "uikit"). Uikit is an adapted version of the top bar in admin, and it's now the default theme for the module. Each theme may include its own settings (Uikit, for an example, allows displaying/hiding some or all of its icons and the ProcessWire mark). Custom theme support is still there, but requires a few modifications: custom theme needs to be selected via module config screen, you need to provide a directory where theme files live, and this directory has to contain (at least) a theme.css file (but optionally also theme.js for custom JS, theme.php for hooks, and config.php for custom module config settings). Oh, and the module is installable via Composer now – just run "composer require teppokoivula/admin-bar" in your sites root directory, or the /site/ directory. New requirements for 2.0.1 are ProcessWire >= 3.0.112 and PHP >= 7.1.0. For earlier version of ProcessWire or PHP, use release 1.1.5 (this version won't be updated anymore, but should work in ancient version of PW and PHP). Below is a screenshot of the "Uikit" theme in action on the Wireframe website. In this case I've disabled the icons from the left side of the Admin Bar – by default each action there would have its own icon as well.

Thanks for reporting this. I'm not quite sure why the Modules Directory won't recognise the module version properly, but I've now updated it manually and so far it seems to stick. The info JSON examples at the API ref show a format that isn't actually supported by ProcessWire itself, so it's a possible that this is a bug in the modules directory parser ?

You may need to be a bit more specific than that: what exactly do you mean when you say that the URL doesn't work? Is the screenshot from your actual site, and if so, could you add a link to that? Or is this an example that you're trying to achieve? Note that I've merged your question to the Markup Simple Navigation support thread. When you have a question related to a specific module, post it to the existing support thread for that module – thanks!

I'm not sure, but take a look at this: https://modules.processwire.com/modules/markup-simple-navigation/ -> hook for custom item string (new in 1.2.0)

Whenever you need something think "Where is it done in the core" and grab ideas from there ? You can see how it is done in ProcessModuleInstall.php I've done it that way recently: $tmpDir = $this->files->tempDir('upload_csv'); /** @var InputfieldFile $f */ $f = $this->modules->get('InputfieldFile'); $f->attr('id+name', "upload_csv"); $f->label = 'foo'; $f->icon = 'download'; $f->extensions = "csv"; $f->maxFiles = 1; $f->descriptionRows = 0; $f->destinationPath = $tmpDir; // when the form is submitted: /** @var WireUpload $ul */ $ul = $this->wire(new WireUpload($f->name)); $ul->setValidExtensions(explode(" ", $f->extensions)); $ul->setMaxFiles($f->maxFiles); $ul->setOverwrite($f->overwrite); $ul->setDestinationPath($f->destinationPath); $ul->setExtractArchives(false); $ul->setLowercase(false); $files = $ul->execute(); if(count($files)) { $file = $f->destinationPath . reset($files); // do something with your file } else { $this->error('No uploads found'); } There is an issue with ajax loaded fields: https://github.com/processwire/processwire-issues/issues/885 And it seems that ZIP is always added to the allowed file endings... Can anybody confirm that? PS: Don't you use TracyDebugger? It's a lot better than using print_r() ?

ProcessWire's database abstraction is the best of all CMS systems I know.