Leaderboard

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!!

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.

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.

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.

Vanilllllllllla js for the win. Although for me its the right tool for the job. Jquery is mostly a sugar to make browsers play nice, and a toolkit of repeatable actions (fade, move, etc). Vue and React are MV* for two way data binding... so basically doing mostly a different job (altough like angular your find front end animation helpers too). Soooo, frameworks go out of fashion (remember when everyone was using Backbone?!), but vanilla won't and right tool for the job.

Ok, you asked for it. The main Dumps panel is now better at reporting bd() calls from obscure places, like other modules, and within Tracy itself. These improvements are fairly well tested, but please let me know if you notice anything it's not reporting that it should. I also added a new "Modules Refresh" option to the PW Info panel. This is not only a useful shortcut on the frontend, but because it returns you to the URL you were on, I actually prefer it to using the "Modules > Refresh" link on the backend as well. I am definitely open to more discussion on this, but at the moment I don't really see a good solution that will work across all panels - information is presented in many different ways in the different panels, so I think we would need to target this to the ones that really need search/filtering.

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)

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

Coming from CMSs that used centralized media, this tripped me up at first too. Convoluted is an understatement. However, I also think allowing users to insert images to their hearts content inside an RTE brings a world of design pain. Moderately related, one client a few years back added so many top level menu items that it spilled onto a new line and looked awful. Now I tightly control what they can and can't do, and that definitely includes image uploading. Maybe it's just me, but I also find working inside an RTE field where images have been inserted really awkward unless they're about 30 rows high. Anyway, the profields repeater matrix is an excellent alternative (for PW v3 and above). You can add body > image > body > image, (with image being just a single image upload field which you can set min/max image sizes). You have much more fine grained control over the final output. I thought it was well worth the £115 or so (whatever the exchange rate is) for unlimited usage. The other profields field types are very useful too that come bundled in. There's also the media manager module (£28 single site, £108 for unlimited use) which I haven't tried but it looks awesome: https://processwireshop.pw/plugins/media-manager/

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.

Interesting you bring this up -- was thinking about it the other day. Would love to see this happen, especially in Vue.

Looks fine so far. What exactly does not work? Are there no projects in the output? Possibly the projects are hidden, in this case the selector looks like this: $pages->find("template=projects,include=hidden")

Hi @ROLAND_JUNO If I'm not mistaken clone module is not installed by default, so you have to install it first and then you will be able to clone pages.

I whipped up a module for this:

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.

Nice article. Made me remember the good old days of Perl golf.

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

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

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?

I just moved a site to a new Ubuntu 16 server and experience the following error: Warning: touch(): Utime failed: Operation not permitted in /var/www/html/wire/core/FileCompiler.php on line 329 Any idea what the problem could be?

@flydev : More beta-tester needed ! Hello can I test your module? I have a lot of sites , someone heavy, so I can test and report

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 }

Yes, you can. Double click on it .

The "http" may be optionally prepended to any property accessed from $config->urls (including those you add yourself). https://github.com/processwire/processwire/blob/57b297fd1d828961b20ef29782012f75957d6886/wire/core/Paths.php#L49

Template caching maybe? Check the Cache tab when editing the relevant template. As for CSS, browser cache? Chrome is notoriously 'cachy!'. You will want to develop with dev inspector open and set not to cache, if that is the case.

Thank you @ryan for pointing me in the right direction. Problem solved. FormBuilder was a red herring, all good there. The cryptic debug message was key to finding the cause. I refer to the home page throughout the site and normally add $homePage = $pages->get('/'); in the _init.php file. Tried to be too clever and tweak page load speed by reducing the number of database calls so put the following below the LoginRegister code: // shortcut to home page saved in session $homePage = $session->get('home-page'); // Fairly certain this is the culprit! if (!$homePage) { $homePage = $pages->get('/'); $session->set('home-page', $homePage); } While the above works for $cache, it doesn't for $session, or even replacing $session with $_SESSION and using array_key_exists('home-page', $_SESSION), etc. Reverted to $homePage = $pages->get('/'); for every page and Login/Register working perfectly.

I saw your question in the FormBuilder linking to this thread, so replying here rather than there because I don't think it's related to FormBuilder, as it doesn't look like you are using FormBuilder for the forms here and as a result it shouldn't come into play. A couple things to look into: I'm wondering if there is an unexpected extra redirect occurring somewhere. It might be good to watch your developer tools Network tab (in Chrome) to look for 301 requests. It could be as simple as a page requiring a trailing slash and one not being present, or the opposite, and thus a redirect occurring. Or it could be that you've got those pages access protected using PW's template access control, and its redirects are happening before your _init.php even gets called. While you are testing, you might want to disable the _init.php code just to see what difference it makes. Take a look at markup regions and make sure that your final output is as you expect when viewing the source of the pages. I noticed you are using the markup region tag termination hint <!--#regPostContent-->, which is good—that gives Markup Regions a shortcut to find where your tag ends, saving it time. But in another case you are using <!-- #content end -->, which might be confusing the markup regions because it should instead be <!--#regContent-->, and I don't see a <div id='content'> in the markup you pasted in. I think markup regions is probably just ignoring your <!-- #content end -->, but try replacing it with <!--#regContent--> just in case.

Unless that's a typo you shouldn't have that dollar sign there.

@flydev I'd like to test too. (Especially after I tried to set up backup/sync cron jobs via a server's crappy control panel where everything just works half-baked...)

My apologies - yes, I see that those vendor libs are also PHP 5.4+ (https://github.com/lesaff/ProcessWire-Sassify/blob/edbbc4dad1a2a38e64a084638cf69aa9c663abe4/vendor/leafo/scssphp/scss.inc.php#L3) I might really be time for PW to dump support for 5.3. Just looking around, Drupal stopped supporting it 3 years ago!

I had the same problem. Everything was fine on XAMPP but not on the live server. The reason is that on the server there is an apache module installed called mod_security. Add the following code on top of your .htaccess file and the problem will be fixed. <IfModule mod_security.c> SecFilterEngine Off SecFilterScanPOST Off </IfModule>

This happens when the user PHP runs as isn't the owner of the cache files. The file compiler tries to update the cache files with the modification time of their originals, and while writing to that file can succeed through group permissions, updating the modification time fails unless issued by the owner. Clearing the cache removes the cache files and recreates them with the PHP user as the owner, so the problem is gone.