Leaderboard

Hi, based on the work of @microcipcip and @gebeer (see their posts here and here), I put together a Processwire + React boilerplate (profile). Github repo: https://github.com/lapico/process-react Cheers, K

This week's version of ProcessWire on the dev branch includes some useful updates to the included AdminThemeUikit module. It also adds a new config setting for disabling HTTPS requirements in dev/staging environments, as well as some other updates: https://processwire.com/blog/posts/pw-3.0.99/

Well, the first time you have to handle such situations is always a bit rough. Lots of trial and error, and trying to stay in sync, but also trying to get the best possible speed performance etc. From what little I could see, the JSON you get is well-structured. There are unique IDs that you could use in your import/update process. There are time-stamps for performances. So, overall you should be fine (not every SaaS who claims it has its own API is actually usable). With projects like this, it's even more important to have a solid test/dev platform. If you have a live site, and add or change features, you don't wanna do it directly first on the production site. I'm sure we'll have suggestions and tips if you run into any problems. That's the most important thing.

Hi @adrian, ___wakeupValue is needed for frontend access. I am assuming some people use the field in the frontend. ___sleepValue should be able to work with return true only. I'll have to investigate deeper though. The whole module is based on Ryan's concat field. These methods were copied as is (or almost) from that module. So, his module must be having the same issues then. I'll have a look sometime. Still no ETA though, sorry.

Thanks @SamC, I understand. I kind-of did it in a test environment, let me explain the full case scenario: A local (and really small) movie theater in my area was looking for a web designer to help them out with their website and primarily their ticket management integration. They absolutely need to sell their tickets on-line. I quickly jumped in to start the negotiations around budget, best solution, how to manage the whole thing, ecc. During our chats I found that there was a widely used ticket management service in Italy called Wintic/Webtic, it is used in around 70% of cinemas in Italy and I knew that very probably I would have to integrate that sooner or later. So I started calling the software house regarding their ways to integrate the whole "thing" in an existing portal. They told me that they made available a webservice with the cinema schedule and send me a link to the JSON I was frightened! Being this the first time I've found myself in a situation (that I was actively avoiding) where I just needed to step out of my relatively comfy zone of CMSs and tackle the issue as best as I could and in a budget friendly way. (The integration with Wordpress is just a headache to think about compared with Processwire) Then I started to read (many times) all the threads regarding JSON import and this one really helped me out understanding the whole process. From that thread and a couple of others I modified the script and now it looks like this: https://gist.github.com/protorob/e6050c78b4bee2dbce59c38234afa0de In the end I came out with a functional mockup that you can find here: http://webtic.artomultiplo.net/ and accepted the job. Full of courage. Now I have a whole lot of new questions regarding the best way to wrap it out, so expect to see me around a little more this time. I'm planing to document the whole process in a very long blog post Now my main "concerns" are regarding: - Automate the create/modify/delete of the schedule comparing differences between the current JSON and a New one - Adding extra information to the events and not losing them when the schedule re-synchronize - Working with AJAX Load more for some parts of the website - Handling the blog I know I'll need a little bit of help specially with the importing script. I'll let you know how it goes

As threatened in the Pub sub forum in the "What are you currently building?" thread, I've toyed around with Collabora CODE and built file editing capabilities for office documents (Libre-/OpenOffice formats and MS Office as well as a few really old file types) into a PW module. If you are running OwnCloud or NextCloud, you'll perhaps be familiar with the Collabora app for this purpose. LoolEditor Edit office files directly in ProcessWire Edit your docx, odt, pptx, xlsx or whatever office files you have stored in your file fields directly from ProcessWire's page editor. Upload, click the edit icon, make your changes and save. Can be enabled per field, even in template context. Currently supports opening and saving of office documents. Locking functionality is in development. See the README on GitHub for installation instructions. You should be reasonably experienced with configuring HTTPS and running docker images to get things set up quickly. Pull requests are welcome! Here is a short demonstration:

I've deleted the RockSqlFinder repo on gitlab and created a RockFinder repo. This will be the final name once I'm done with testing + writing docs. I've also added a simple tester process module to quickly inspect and test find operations: Note that this processmodule requires RockGrid which is not available for public yet, so this screenshot is just a sneak peak what will come.

Hi Alex. Not yet. Illness, Easter and Hay Fever all colluded against me. Please note that I'm also upgrading Jquery File Upload alongside Media Manager. I'm working as fast as I can .

There should be an "unselect" button next to the selected page. Similar to the select button, this also becomes visible when you hover over the page. If that doesn't appear for you, I'd recommend submitting a new issue at GitHub.

The wire render pattern (by clsource) is just another example of how you can use the amazing potential of Processwire. Instead of the $viewBag you can use any other $dataBag as you see fit that not need to be updated inside _main.php Processwire now also has the region() function and fields can use a template for even more file and code organization.

https://inovtex.com/noticias/inovtex-vence-nomeacao-site-da-semana-pela-processwire/ nice one

@adrian, looking at the commit that introduced the issue, it looks like removing the autocomplete attribute is an attempt to defeat this piece of InputfieldPassword.js. That piece of JS is a fairly old (and hacky) response to a browser-specific (Firefox) issue that probably no longer applies. The recent autofill fixes in InputfieldPassword and updates/bug-fixes to Firefox should have solved it without the need for that JS workaround (I tested quickly in the latest Firefox and couldn't see any issue with the JS removed). So you could raise a GitHub issue/request to see if Ryan will remove that JS. In the custom module I made for a project recently I took a different approach to auto-generated passwords. Rather than populate the core password field I manipulated the ProcessUser form to... 1. Hide the password field with CSS 2. Add a markup field to show the user the auto-generated password 3. Add a hidden field containing the auto-generated password Then in a before hook to InputfieldPassword::processInput I copy the password value from the hidden field to the password field in $input. That may not be an approach you'd want to take with your module, but just to show there might be other ways to tackle things if Ryan doesn't want to remove that problematic JS.

The issue is exactly as you described it in the GitHub issue I linked to above. It is related to the browser autofilling the password field, so it depends on the form history that is saved in your browser. It's not the kind of thing that will always cause a problem, more one that can (but shouldn't) cause a problem. The fix that Ryan pushed to the core was to avoid that.

Hi, just wanted to share something I came across while working on an import module for XML data from a web service. The XML I got was not huge, but still, loading around 3.5 MB of XML with 250+ large child nodes into memory at once with simplexml_load_file() and then looping over it had significant impact on performance. I searched for a solution and found this great article about how to parse large XML files. It basically explains how to utilize the native XMLReader class together with SimpleXMLElement to handle such situations in a memory efficient way. After implementing it I got a significant improval on perceived performance. No comparison in numbers to share here as I'm a bit short on time.

Hi @adrian, just a heads up: I was again experiencing this issue that you raised in the PW issues repo a while ago: https://github.com/processwire/processwire-issues/issues/432 It was a bit puzzling but I traced it back to the Email New User module which I was testing out. Due to this commit the module is undoing the fix that was applied in the PW core.

I still can't reproduce the issue. I notice that the way you are creating new repeater items does not follow the documentation to the letter: Note that the new repeater page is saved before adding it to the repeater field. Also the repeater page values are set before adding the page, but I don't think that should make a difference in the way you are doing it. But even when I do it the way you are I don't experience any problem:

imho wireRenderFile is still the best way if you want syntax highlighting in your editor; you can then set the $var = wireRenderFile('file', $vars); you could also use static html files with simple {{tokens}}, load one into a variable and str replace the tokens..