Leaderboard

» A more exhaustive version of this article is also available on Medium in English and German « First, we'd like to thank the very helpful community here for the excellent support. In many cases we found guidance or even finished solutions for our problems. So a big THANK YOU!!! We are pleased to introduce you to the new Ladies Lounge 18 website. The next ICF Women’s Conference will take place in Zurich and several satellite locations across Europe. We embarked on bold new directions for the development of the website — in line with the BRAVE theme. Ladies Lounge 18 — ICF Woman’s Conference website on Processwire ICF Church is a European Church Movement that started 20 years ago in Zurich and since experienced tremendous growth. There are already well over 60 ICF churches across Europe and Asia. ICF is a non-denominational church with a biblical foundation that was born out of the vision to build a dynamic, tangible church that is right at the heartbeat of time. With the growth of the Ladies Lounge from a single-site event to a multi-site event, the demands and challenges to the website have also increased. A simple HTML website no longer cuts it. Simplified frontend Our goal with the development of the new site was it to present the different locations — with different languages and partly different content — under once uniform umbrella — while at the same time minimising the administrative effort. In addition to the new bold look and feel, this year’s website is now simpler and easier and the information is accessible with fewer clicks. Some highlights of the new website Thanks to processwire, all contents are maintained in one place only, even if they are displayed several times on the website 100% customised data model for content creators Content can be edited directly inline with a double-click: Multi-language in the frontend and backend Dynamic Rights: Editors can edit their locations in all available languages and the other content only in their own language Easy login with Google account via OAuth2 Plugin Uikit Frontend with SCSS built using PW internal features (find of files…) Custom Frontend Setup with Layout, Components, Partials and Snippets Only about 3 weeks development time from 0 to 100 (never having published a PW before) Despite multi-location multi-language requirement, the site is easy to use for both visitors and editors: The search for a good CMS is over It’s hard to find a system that combines flexibility and scope with simplicity, both in maintainance and development. The search for such a system is difficult. By and large, the open source world offers you the following options: In most cases, the more powerful a CMS, the more complex the maintenance and development It is usually like that; The functionality of a system also increases the training and operating effort — or the system is easy to use, but is powerless, and must be reporposed for high demands beyond its limits. Quite different Processwire : You do not have to learn a new native language, you don’t have to fight plugin hell and mess around with the loop, you don’t have to torment yourself with system-generated front-end code or even learn an entierly new, old PHP framework . All our basic requirements are met: Custom Content Types Flexible and extensible rights-management Multilanguage Intuitive backend Well curated Plugin Directory Actually working front-end editing Simple templating with 100% frontend freedom In addition, Processwire has an exceptionally friendly and helpful community. As a rule of thumb, questions are answered constructively in a few hours . The development progresses in brisk steps , the code is extremely easy to understand and simple. Processwire has a supremely powerful yet simple API , and for important things there are (not 1000) but certainly one module which at least serves as a good starting point for further development. Last but not least, the documentation is easy to understand, extensive and clever . Our experience shows, that you can find a quick and simple solution with Processwire, even for things like extending the rights-management — most of the time a highly complex task with other systems. This is also reflected positively in the user interface. The otherwise so “simple” Wordpress crumbles when coping with more complex tasks. It sumbles over its apparent simplicity and suddenly becomes complex: Old vs. New — Simple and yet complicated vs. easy and hmmm … easy Our experience with Processwire as first-timers Before we found out about Processwire, we found CraftCMS on our hunt for a better CMS. We were frustrated by the likes of Typo3, WP or Drupal like many here. CraftCMS looked very promising but as we were digging deeper into it, we found it did not met our requirements for some big projects in our pipeline that require many different locations, languages and features. Initially we were sceptical about Processwire because; A. CraftCMS Website (and before UiKit also the admin interface) simply locked much nicer and B. because it is built on top of a Framework It was only later, that we found out, that NOT depending on a Framework is actually a very good thing in Processwire's case. Things tend to get big and cumbersome rather then lean and clean. But now we are convinced, that Processwire is far superior to any of the other CMS right now available in most cases. The good Processwire is the first CMS since time immemorial that is really fun to use (almost) from start to finish— whether API, documentation, community, modules or backend interface. Every few hours you will be pleasantly surprised and a sense of achievement is never far away. The learning curve is very flat and you’ll find your way quickly arround the system. Even modules can be created quickly without much experience. Processwire is not over-engineered and uses no-frills PHP code — and that’s where the power steams from: simplicity = easy to understand = less code = save = easy maintanance = faster development … Even complex modules in Processwire usually only consist of a few hundred lines of code — often much less. And if “hooks” cause wordpress-damaged developers a cold shiver, Hooks in Processwire are a powerful tool to expand the core. The main developer Ryan is a child prodigy — active, eloquent and helpful. Processwire modules are stable even across major releases as the code base is so clean, simple and small. There is a GraphQL Plugin — anyone said Headless-CMS?! Image and file handling is a pleasure: echo "<img src='{$speaker->image->size(400, 600)->url}' alt='{$speaker->fullname}' />"; I could go on all day … The not soooo good Separation of Stucture and Data The definition of the fields and templates is stored in the database, so the separation between content and system is not guaranteed. This complicates clean development with separate live- and development-environments. However, there is a migration module that looks promising — another module, which is expected to write these configurations into the file system, unfortunately nuked our system. I'm sure there will be (and maybe we will invest) some clever solutions for this in the future. Some inspiration could also be drawn here, one of the greatest Plugins for WP: https://deliciousbrains.com/wp-migrate-db-pro/ Access rights The Access-Rights where missing some critical features: Editors needed to be able to edit pages in all languages on their own location, and content on the rest of the page only in their respective language. We solved it by a custom field adding a relation between a page the user and a role that we dynamically add to the user to escalate access rights; /** * Initialize the module. * * ProcessWire calls this when the module is loaded. For 'autoload' modules, this will be called * when ProcessWire's API is ready. As a result, this is a good place to attach hooks. */ public function init() { $this->addHookBefore('ProcessPageEdit::execute', $this, 'addDynPermission'); $this->addHookBefore('ProcessPageAdd::execute', $this, 'addDynPermission'); } public function addDynPermission(HookEvent $event) { $message = false; $page = $event->object->getPage(); $root = $page->rootParent; $user = $this->user; if ($user->template->hasField('dynroles')) { if ($message) { $this->message('User has Dynroles: '.$user->dynroles->each('{name} ')); } // for page add hook… if ($page instanceof NullPage) { // click new and it's get, save it's post… $rootid = wire('input')->get->int('parent_id') ? wire('input')->get->int('parent_id') : wire('input')->post->parent_id; if ($message) { $this->message('Searching Root '.$rootid); } $root = wire('pages')->get($rootid)->rootParent; } elseif ($page->template->hasField('dynroles')) { if ($message) { $this->message('Page "'.$page->name.'" has Dynroles: '.$page->dynroles->each('{name} ')); } foreach ($page->get('dynroles') as $role) { if ($role->id && $user->dynroles->has($role)) { if ($message) { $this->message('Add dynamic role "'.$role->name.'" because of page "'.$page->name.'"'); } $user->addRole($role); } } } if (!($root instanceof NullPage) && $root->template->hasField('dynroles')) { if ($message) { $this->message('Root "'.$root->name.'" has dynamic roles: '.$root->dynroles->each('{name} ')); } foreach ($root->get('dynroles') as $role) { if ($role->id && $user->dynroles->has($role)) { if ($message) { $this->message('Add dynamic role "'.$role->name.'" because of root page "'.$root->name.'"'); } $user->addRole($role); } } } } } With the Droles and Access Groups Modules we were not able to find a solution. I thought it was hard to get absolute URLs out of the system — Ha! What a fool I was. So much for the topic of positive surprise. (Maybe you noticed, the point actually belongs to the top.) But while we’re at it — that I thought it would not work, was due to a somewhat incomplete documentation in a few instances. Although it is far better than many others, it still lacks useful hints at one point or another. As in the example above, however, the friendly community quickly helps here. processwire.com looks a bit old-fashioned and could use some marketing love. You notice the high level to moan with Processwire. There is no free Tesla here. Conclusion Processwire is for anyone who is upset about any Typo3, Wordpress and Drupal lunacy — a fresh breeze of air, clear water, a pure joy. It’s great as a CMF and Headless CMS, and we keep asking ourselves — why is it not more widely known? If you value simple but clean code, flexibility, stability, speed, fast development times and maximum freedom, you should definitely take a look at it. You have to like — or at least not hate PHP — and come to terms with the fact that the system is not over-engineerd to excess. If that’s okay with you, everything is possible — with GraphQL you can even build a completely decoupled frontend. We are convinced of the simplicity of Processwire and will implement future sites from now on using it as a foundation. Links & resources we found helpful API documentation and selectors API cheatsheet pretty handy, not quite complete for version 3.0 Captain Hook Overview of Hooks Weekly.PW newsletter a week, exciting Wireshell command line interface for Processwire Nice article about Processwire Plugins & Techniques that we used Custom Frontend Setup with Uikit 3 and SCSS, and Markup Regions Uikit Backend Theme ( github ) Oauth2 login modules In-house development Login with E-Mail Pro Fields for repeater matrix fields (infos, price tables, daily routines) Wire upgrade to update plugins and the core Wire Mail Mandrill to send mails FunctionalFields for translatable front-end texts that are not part of a content type (headings, button labels, etc.) Runtime markup for dynamic backend fields (combination of first and last name) Tracy debugger for fast debugging Textformatter OEmbed to convert Vimeo and Youtube links into embed codes HideUneditablePages thanks to @adrian

Hey everyone - don't forget to read the version of this excellent post on Medium: https://medium.com/icf-church-developers/our-first-processwire-website-fab741e09707 Create an account and "clap" for the article - you can clap up to 50 times - let's see if we can get @noelboss's article on the Medium homepage!

Just clicking 'like' doesn't seem enough.

Since GitLab doesn't support simple basic auth, you're out of luck with "username:password@" in front of the url. But you can set the "private_token" parameter like this: https://mygitlabserver.com/myrepo/repository/master/archive.zip?private_token=2CEgvKCfrABgshElokZ3 The private token can be generated within the GitLab personal user settings. This should get you going: https://mygitlabserver.com/profile/personal_access_tokens - replace "mygitlabserver.com" with the url of your GitLab server.

I think in my case it was Typo3

I was looking for a module that allows the execution of long-running tasks (working with tens of thousands of pages) and could not find a suitable solution. It started with the import problem. I have lots of data in XML form (20k+ complex entries) that I want to import into ProcessWire. XMLReader() works fine but it takes a very long time to import all data so a simple "upload + process data on page save" would not work. So I've created a new module for this. Meet my first (well, third) PW module: Tasker. It's a simple module that executes long tasks in the background (using Cron or LazyCron) and reports their status to the user using a JQuery progressbar. Any suggestions are welcome. How do you solve similar problems? E.g. which is the best way to delete large number of pages? (max_exec_time will expire so I check it before the delete() call.) $children = $page->children('template='.$this->template.',include=all'); // creates lot of page objects, may not have time to delete all + ...->delete() OR $childIDs = $this->pages->findIDs('parent='.$page->id.',template='.$this->template.',include=all'); // will create page objects later + $pages->get(..id..)->delete() Be nice (I know you're always), I'm a PW-newbie, just started working with ProcessWire. I was developing sites with Drupal for a very long time but their non-existent module upgrade path finally has driven me away from it.

I'm not strictly against ditching jQuery in favour of Vue / React / whatever it is that all the hip developers use right now, but it's true that this would be a major change, and I'm not sure how much sense it would really make. "That's what others are doing" is not a very good reason in itself, but if it would enable us to do something that we currently can't, I'm all ears (Note: in the end this decision is obviously up to Ryan, and as far as I know there are currently no plans for ditching jQuery / jQuery UI.) Personally I'm still somewhat fond of jQuery. It simplifies a lot of stuff, deals with browser incompatibilities, and provides polyfills for some missing features. It's not the best tool for massive JavaScript applications, but that's not what the admin is all about either. Also, minified and gzipped jQuery 3.x is 32Kb, so anyone calling it "huge" could use a reality check. Sure, it is huge if you're only using it to implement a simple slider or menu or something along those lines, but that's a rather limited use case. That being said, it is true that the core is currently using a relatively old version of jQuery, so going up a couple of major versions could be a good first step? --- On a related note: at least a couple of third party modules already use Angular, and back in the day Antti even released a module that automatically loads it. For third party stuff it could make sense to build a set of modules for loading common frameworks and then require those as needed. That won't solve the problem of having to load jQuery and it won't make the entire admin a Vue/React/whatever app, of course.

These are the articles we need! So many thanks @noelboss! We need more articles like this. We have built a great application for an international corporate using ProcessWire with over a million (1.000.000) pages and counting and hundreds of concurring users all over Europe and the United States. We built it right in the back-end of ProcessWire using ListerPro and +/- 20 custom Process Modules. Unfortunately I can't write a showcase (I'm dying too ...) due to legal stuff. I could not agree more with one of the disadvantages: Thanks again! I clapped 50 times

AFAIK you don't need to check $page->editable when using FEEL.

Tankä, as we say in Zurich Frontend editing comes bundeled with the Processwire core! In addition we use Front-End Edit Lightbox (FEEL) like this; echo $page->feel( [ 'text' => $page->template->get('label|name').' '.ukIcon('pencil'), 'class' => 'uk-button uk-button-small uk-button-default cp-editpage', 'fields' => null, ]);

Oh, and it also reminds me of my most favorite "inheritance" at work. Someone, long before I joined the company and no longer available (their luck!), created an Approach database for test run data, and I was asked to "import it into a real database system and make it work offline". It had a few tables named X123 or X345 so you could easily identify their contents. Not. Every table had fields with descriptive names like F1 to F98 or B1 to B45, etc. It also had lots and lots of formulas on the form fields, using expressive variables named a, x, ab, ac... you get it. To make matters not too easy, the database fields could contain different semantic data depending on what kind of machine the report was for, i.e. what form was used to enter the data, and not all forms limited the accessible rows accordingly. Formatting of values was done by copying them back and forth between the database and hidden fields on sometimes unrelated forms. This was still something I could wrap my head around to a degree, but I soon discovered (by trial and error with a copy, since the code was bound individually to each of the 300+ form fields) thrilling little rules like "If the report is in German, then field F68 contains the description of the setup and F92 contains the English translation, but if the report is in English, F68 contains the internal addendum and F70 contains the English setup description, and the German translation can be found in F69." A true blessing when you want to use a standard reporting package to generate the PDF output. And did I mention that the charset could differ between rows without any indication in the data or record metadata? It think this was the first time that I had actual tears in my eyes after looking at a piece of software.

Good to see I'm not the only one scratching my head over the current jQuery-is-bad movement. To me, wiring in a full-fledged MVsomething framework only makes sense if the complete data exchange is abstracted away, otherwise backend code and frontend (speak backend UI) logic will get even tighter bundled (or bungled?). This would mean that all backend calls would need to be some kind of RESTful using JSON, XML or something along these lines, and plainly, PW isn't at that point right now and getting there would need quite a bit of work. I'm not a real wiz when it comes to MVC/MVVM frameworks, but I do have some experience building complex RIAs, starting by building everything on top of ExtJS (2 and 3) in the good old days and later rolling my own two-way bindings for nested data structures. I've recently delved a bit into the currently trending frameworks, and I was utterly appalled by the unnecessary complexity, semantic mumbojumbo and lack of essential features each of those exhibited in varying degrees. Don't get me started on the massive breaking changes introduced in major frameworks I see every year. I've got one really complex app that needs a larger overhaul next year (warranted after 8 years, I feel), and I've come to the conclusion that it will be simpler, faster and more concise to build everything without any framework besides a lean CSS library and perhaps jQuery, especially if I want it to run the following 5+ years without finding myself using an orphaned framework. If the PW backend could be completely JSONified, I'd be all for that, but even then, I'd currently prefer a framework-less default interface. Any MV* solution could then be an alternative, just like current admin themes.

Hi Everyone, all around the Internet i see developers advice to not depend on jQuery anymore, (Frameworks & CMS's ) for example: Bootstrap Bootstrap 4 Without jQuery UiKit Uikit 3 Beta-31-released Silverstripe CMS - Silverstripe and many more .. I wanna know what is the situation gonna be with (ProcessWire + jQuery)? Any RoadMaps related to it? The current included version in "wire" directory is jQuery v1.11.1 .. is it possible to use PW with Vuejs or React (I'm Talking about the core not the frond-end development)

Hi everyone. I've made a tiny module for adding a folder select input in the admin, this allows you to select a folder path from the dropbox account associated with the DropboxAPI module. This module requires the above DropboxAPI module to work. I made this with a lot of great advice from @abdus though much simpler than I think they would have done it. TBH I got totally confused about how to implement fieldtypes and inputfield modules and I hope that there could be an effort for tutorials or docs on this - e.g. requirements to register a inputfield, setting and using config options, interacting with the input on a page, creating a fieldtype and requirements, schema best practise.. etc. https://github.com/benbyford/InputfieldDropbox install / setup: DropboxAPI module download and install DropboxAPI module, adding to your site/modules folder install in modules section of admin goto: https://www.dropbox.com/developers/apps add new app choose dropbox api, folder access, then name the folder which will appear in your dropbox /apps/ copy api codes and add to DropboxAPI settings. InputfieldDropbox module download and install InputfieldDropbox module, adding to your site/modules folder install in modules section of admin add new textarea field in processwire admin, save within Details tab, select Dropbox on Input type select box. This gif shows me selecting from options found within my dropbox account within folder /apps/theNameOfTheRegisteredFolder.

Hello everyone, I spend my sunday hacking a playground for the new admin theme together. Unfortunately it took almost the whole sunday, Fortunately it was raining anyway. If you find bugs or annoyances, please feel free to tell me about them. What is it? It is a backend with an integrated skin editor. In this weeks blog post @ryan showed how easily skinnable the new admin theme is. Now that can be done online without having to set up ProcessWire and LESS compilation (I did that for you). Show me http://pwadmin.youbility.de/processwire/ username: admin password: admin123 Why did you do that? I really think the new backend is one of the three key factors for ProcessWires future success (as well as the new website and the documentation; basically the things a user sees first when he's deciding for a CMS). Many many weeks ago, when Ryan introduced the new theme, he said he will need help from the designers in the community to create the best experience possible. As far as I've seen, since then there was not that much input from the community. I hope a ready-to-run theme editor can improve that a bit. How does it work? Right of the search field there's a new icon which opens the editor. Simply create a new skin and start playing with it. The skin will be available throughout all the session, even if you refresh or change to another skin. When you log out or lose your session the skin will be gone, so save your final result somewhere else too!! What other features will come? Probably none, unless there's something heavily requested. I could probably add something to store the skins permanently through LocalStorage. Or I could add more possibilities for customization than just the LESS file. But first I'd like to see if this is used and there's even the need for those features. Can I show my created skin to others? Of course. Right now just "default" and "pw-theme-reno" are public. I would love to show more skins there. Just post the content of your skin in this thread and I will add them to the public skins. I hope you find it useful and it helps making the most efficient and polished CMS backend out there.

I'm in the web design since 1998, and I remember when the war against inline styles began, you put a little style="margin-bottom:10px" in a unique element in the project and you are a renegade man from the old days, you need to create a new css class for it ... after decades learning to avoid them at all cost.. now in 2017 the new trend that coder influencers propose as good modern practices (because of React, etc) is using it! you get this and is OK.. Whaaat? !! ..hahaha.. the previous was a joke.. but seriously.. the best practice is to be practical, logic and simple always as @BitPoet said

Congrats to your new module. I'm sure it will be a godsend for large import (or utility) tasks. I hope I'll have time to try it out soon. As for your question: I guess I'd try to first get the IDs. And I'll probably also use findMany() - apparently it's faster than find(). https://processwire.com/api/ref/pages/find-many/ https://processwire.com/blog/posts/find-and-iterate-many-pages-at-once/

So, we should build the next PW admin without uikit framework too? Because we will no longer depend on jQuery but will depend on UIKit or any other library that we need to function properly. Really I don't understand which is the trending goal of eliminating jQuery like a disease?

Technically PW Admin uses the API available. It's just a front end. So if someone wants to create a totally new admin front end that uses some js libs like https://vuejs.org/ https://mithril.js.org/ https://preactjs.com/ http://www.celljs.org/ It's totally possible. But keep in mind that many third party modules depends on jQuery. So if this is implemented in the core it should be ProcessWire 4 or something indicating a huge change.

Thank you @adrian !

Sure .

Really great post, thanks for sharing @noelboss. Signed up to medium and did the above too, PW def needs some more exposure as does this write up.

I know this behave. You need to save it 2 - 3 times during the switch process. I believe this has to do with pw core, not only that module.

Thanks for the report @adrian. I have fixed this in v0.0.2. Now the Save + Add New button is not added when editing inside a modal, as I don't think it's desirable in those circumstances (another case of this is when editing a field's template context from the template editor).

https://javascript.info/ninja-code Quite enjoyed reading this one. Thought I'd share

Never heard of it. Which is a good thing by the sounds of it

Completely unrelated to this thread but thanks for sharing this @abdus. I've been looking for a way to serve up 'file.css' on local and 'file.min.css' on a live version and I never thought of using debug being true/false to change the file extension. Right now I have two header files and I have to awkwardly edit each one whenever something changes. Gonna implement something similar immediately! (and now to just remember to turn debug mode off on live site...) =EDIT= Did this in the end: // /templates/includes/header.php <link rel="stylesheet" type="text/css" href='<?= "$assets{$prependedFolder}css/styles.{$ext}css"; ?>' /> // /templates/_init.php (prepended) $templatesUrl = $config->urls->templates; $assets = $templatesUrl . "site-assets/"; $prependedFolder = $config->debug ? "src/" : "dist/"; $ext = $config->debug ? "" : "min."; Works great.

Hey @Robin S - this seems to break the "create a new field" option from the Template editor. It tempts you with a new "Save and Add New", but without clicking the "Add & Close" button, the new field won't be added to the template.

Nice! (or "chapeau", as we say in Zürich). The article even in two languages! How did you do the inline frontend editing feature? Custom developed or a module?

With your code: $options = $fieldtypes->get('FieldtypeOptions')->getOptions("experienced_in")->title; Much shorter and probably much easier in page context: $optionsId = $page->optionsfieldname; // the ID $optionsValue = $page->optionsfieldname->value; // the value $optionsTitle = $page->optionsfieldname->title; // the title

Alternatively you can hold down the shift button and click refresh to clear the cache for the website and refresh.

hi donald, the module is not intended to be used on the frontend. though it is not that hard to do it... example home.php <!DOCTYPE html> <html lang="en"> <head> <meta http-equiv="content-type" content="text/html; charset=utf-8" /> <title><?php echo $page->title; ?></title> <link rel="stylesheet" type="text/css" href="https://cdnjs.cloudflare.com/ajax/libs/handsontable/0.34.5/handsontable.full.min.css" /> <script type="text/javascript" src="https://cdnjs.cloudflare.com/ajax/libs/handsontable/0.34.5/handsontable.full.min.js" /> </head> <body> <h1><?php echo $page->title; ?></h1> <?php if($page->editable()) echo "<p><a href='$page->editURL'>Edit</a></p>"; ?> <?php bd($page->cars); ?> <div id="example"></div> <script type="text/javascript"> var container = document.getElementById('example'); var hot = new Handsontable(container, { data: <?= json_encode($page->cars->data) ?>, rowHeaders: false, colHeaders: <?= json_encode($page->cars->colHeaders) ?>, }); </script> </body> </html> the field config for the backend: $(document).on('afterInit.rht', '.handsontable', function(e, hot) { var colheaders = ['Volvo', 'Audi', 'BMW']; hot.updateSettings({ colHeaders: colheaders, minCols: colheaders.length, maxCols: colheaders.length, maxRows: 1, minRows: 1, rowHeaders: false, }); }); i don't know any technical details of the other module. i built this module to have a quick and easy way to INPUT some table data and be able to copy&paste from excel. for me the benefits of this module compared to the matrix field is the look&feel. it's more compact and more excel-like, so it's easier to grasp for my clients. but the field has some major limitations you have to keep in mind. for example changing inputfield config after some data already has been stored would lead in data destruction. its also not possible to use this data in selectors. and multilang values are not supported. thats no problem as long as you have only have numbers as data because you can translate column headers (see above example).

Pithy comment alert: If its not broke. Give it ago a report back (this harps back to simply making your own admin using the API). and Age over beauty (there's probably more where those come from

I've just upgraded to PW 3 (3.0.62) and I'm seeing minor speed improvements on our Test Server. Before : 3.9s for full document load After : 3.7s for full document load Edit : I was on PW 2.8.x previously

In Chrome, with dev tools open, you can long-click the refresh button for browser cache-busting super powers.

That was it! Thank you so much! So first save the empty new item AND THEN populate it! BIG THANKS!

Do you mean a new item in an existing repeater field? This post shows how to do that: https://processwire.com/talk/topic/6435-cant-figure-out-how-to-create-a-repeater-through-the-api/?do=findComment&comment=62987 Is that what you are wanting?

You can install the core LanguageSupport module and then "translate" the string for the Default language:

That has something to do with the famous Turbo Entabulator®, hasn't it?

What @kongondo said for sure! I always keep the dev tools open now, css and js caching was a nightmare for me. This stops that, 'alt+cmd+i' on a macbook. Can't remember the windows desktop combo, maybe 'shift+alt+i'.

Don't forget the classic https://github.com/Droogans/unmaintainable-code https://goo.gl/xAt1P2

Cool JS frameworks will become history just because sooner than later someone releases just another even cooler JS framework rendering the previous ones obsolete. BTW, the WordPress guys have been debating for months or maybe for more than a year which one to pick... On the other hand, jQuery is still going strong as others have also pointed it out above.

I'm very interested why foremost it's age is a good reason to turn away from jQuery. It's no new cool kid on the block, but it is matured, very well documented and wide spread. It was no "dead end" like some of the other "cool" JS frameworks have been. It feels like a good ol' companion. It's not the right tool for every job nor a holy grail, but in pretty much use cases it works well and affordable in a sense that there is no steep learning curve.

Maybe of use? https://github.com/shancarter/Mr-Data-Converter

For me, the reality is that when I use "vanilla" scripts, each one coming from different developers with its own code for dom traversal and manipulation, yes they are in plain js without dependencies ... but with a tons of redundant code for the same tasks ... so when I finally managed to finish a complex website with sliders, accordions, calendar, date selectors, drop-down menus, parallax, forms and looong, etc. each has its own code to select nodes, add/remove classes and looong, etc. I have a lot of repetitive code, for what? For a trend? yes it's true jQuery 1x is obsolete and fat due to the support of old browsers, but jQuery 3x is as slim as you need. The reality is that we need a library for common tasks (give it the name you want). For today jQuery allows me to do simple tasks on a regular website without additional efforts (ie a website like processwire.com, not a web application, or a project for Córdoba).. well.. if someone create that library, pleeeease use an API similar to PW/JQUERY.. it's so easy to use and learn for us, the non pro developers!!

If Jquery is removed i'd like to see plain vanilla js and no framework in between. Just like like there is no PHP framework in PW.

I face a similar problem, 20k+ entries from external sources. XMLReader() is quite fast and has low memory usage. It's also pretty simple if you understand its logic. $xml = new \XMLReader(); $xml->open($file->filename); while($xml->next('tagName')) { if ($xml->nodeType != \XMLReader::ELEMENT) continue; // skip the end element ... process attributes ... $xml->getAttribute('attr') ... inner or outer XML ... $xml->readOuterXML() ... you can even convert it to SimpleXML or DOM }

Just a heads up regarding a possible fix posted in the GitHub issue: https://github.com/processwire/processwire-issues/issues/411#issuecomment-340139239

I was expecting to find a method to hook before admin theme in the hopes that I could modify $config->styles, but unfortunately there's none. Here's how AdminThemeDefault uses it: // /wire/core/modules/AdminTheme/AdminThemeDefault/default.php $config->styles->prepend($config->urls->root . "wire/templates-admin/styles/AdminTheme.css?v=$version"); $config->styles->prepend($config->urls->adminTemplates . "styles/" . ($adminTheme->colors ? "main-$adminTheme->colors" : "main-classic") . ".css?v=$version"); $config->styles->append($config->urls->root . "wire/templates-admin/styles/font-awesome/css/font-awesome.min.css?v=$version"); $ext = $config->debug ? "js" : "min.js"; $config->scripts->append($config->urls->root . "wire/templates-admin/scripts/inputfields.$ext?v=$version"); $config->scripts->append($config->urls->root . "wire/templates-admin/scripts/main.$ext?v=$version"); $config->scripts->append($config->urls->adminTemplates . "scripts/main.$ext?v=$version"); ... <head> ... <script type="text/javascript"><?php echo $helpers->renderJSConfig(); ?></script> <?php foreach($config->styles as $file) echo "\n\t<link type='text/css' href='$file' rel='stylesheet' />"; ?> <?php foreach($config->scripts as $file) echo "\n\t<script type='text/javascript' src='$file'></script>"; ?> <?php echo $extras['head']; ?> </head> Here's how AdminThemeReno uses it: // /wire/core/modules/AdminTheme/AdminThemeReno/default.php // Styles $config->styles->prepend($colorFile . "?v=" . $version); $config->styles->prepend($config->urls->root . "wire/templates-admin/styles/AdminTheme.css?v=$version"); $config->styles->append($config->urls->root . "wire/templates-admin/styles/font-awesome/css/font-awesome.min.css?v=$version"); // Scripts $config->scripts->append($config->urls->root . "wire/templates-admin/scripts/inputfields.$ext?v=$version"); $config->scripts->append($config->urls->root . "wire/templates-admin/scripts/main.$ext?v=$version"); $config->scripts->append($config->urls->adminTemplates . "scripts/main.$ext?v=$version"); ... <head> ... <script type="text/javascript"><?php echo $helpers->renderJSConfig(); ?></script> <?php foreach($config->styles as $file) echo "\n\t<link type='text/css' href='$file' rel='stylesheet' />"; ?> <?php foreach($config->scripts as $file) echo "\n\t<script type='text/javascript' src='$file'></script>"; ?> <?php echo $extras['head']; ?> </head> There arent any method calls anywhere. BUT, with my SUPER hacky way, you can intercept the styles as they're added to $config->styles. <?php namespace ProcessWire; // /site/templates/admin.php class MyFileArray extends FilenameArray { private function intercept($filename) { if (strpos($filename, '/templates-admin')) return true; elseif (strpos($filename, '/AdminTheme')) return true; } public function append($filename) { if (!$this->intercept($filename)) { parent::append($filename); } } public function prepend($filename) { if (!$this->intercept($filename)) { parent::append($filename); } } } /** @var Config $config */ $config->styles = new MyFileArray(); require($config->paths->adminTemplates . 'controller.php');

If a client is dead-set on WordPress, it's worth communicating to them that every developer has their own go-to approach with the system, to the point where I would say it's not even "WordPress" anymore. So even if another developer were to take over it, it's still foreign territory to an extent, followed up with continuously saying "why the hell did the previous developer do things in X way instead of Y?" and a lack of productivity. Just check out all the starter themes, mega themes (ugh... ... ... ugh), and different approaches to custom fields. It's pretty terrible. For me, ProcessWire + UIkit solves like 95% of my challenges, and solves them WELL.