Leaderboard

I've been thinking of adding this for a while. Now configurable in v0.3.10

Hi @thetuningspoon Thanks! I took 3.1.6 from GitHub, it doesn't seems to be push to PW modules repository. But anyway, it works perfectly now!

Hi @mel47, I just pushed out a release that I believe fixes this. Can you confirm? It looks like there was a small issue with @kixe's pull request a while back that I didn't catch.

That's an nginx error. You need to increase the client_max_body_size setting in nginx.conf.

I don't know Swift but I see it's a language to develop Apple applications. At first instance I don't feel this is related with using static method in PHP, as it looks related with Python and multi-threading. ? EDIT: Just in case @donatas, are you using php-fpm? Because PHP error log could be in another location and not in Apache.

Upgrading plugins? Contact Form 7 changed IDs in their shortcodes for embedding forms from incrementing integers to hash based strings. From the release notes: orly. You see- upgrading the plugin replaced all of the IDs for the forms. It didn't add hashing, it replaced all of the integer IDs in the database during the plugin update process. Instant borkification. I've dipped my toes in programming once or twice and I can tell you that seems like a pretty big oversight... TO THE GOOGLES! First result was a support thread for this issue on the plugin's website. Hey- marked resolved, day has been saved! But there's no actual solution in the thread. IT WAS A RUSE. So here we are. Just in case anyone using WordPress needing help on Contact Form 7 is still looking for a solution and stumbles on this thread, I'll provide it here on a different CMS' support forums: Go through your entire site and replace all of the existing shortcodes for all of the forms wherever they were added on pages and templates with the new ones. By hand. Couldn't be easier. The mostest popularest user-friendliest CMS strikes again.

I think it's a good point, and prior to more recent versions, PW included several site profiles. But by and large the community preferred PW to be slim and not include all the site profiles, so we changed it to just include 1 profile (the minimal blank profile). This is the preference of established users of ProcessWire. But for new users that might not already be familiar with PW, I think having something more for a site profile is preferable. The solution is for PW's installer to be able to download the other profiles automatically if the user wants them. I think this was brought up before, but I haven't done it yet, though perhaps should soon.

Oh, what's this? Another completely different site borked itself? Performed an update using an automated tool through the web host where the core and all plugins are updated at the same time. Is there a right way to update WordPress? The world may never know... This update has has rendered the Admin unusable and inaccessible. Time for a server rollback! Okay! We're back... oh boy... Did you know? Deactivating plugins in the wrong order can make the plugins page hang on a redirect loop every time you try and access it. Time for a server rollback! (Before someone says "that was a caching issue", no it wasn't) Okay! We're back... oh boy... Did you know? In WordPress, a commercial theme or plugin you've purchased and installed may install other commercial plugins that require their own license. When that license expires, you may have to pay for a separate license for the plugin that the plugin/theme you already purchased installed when it comes time to upgrade. PROTIP: the commercial plugins that were installed by the theme or plugin you purchased are not easily recognized as a dependency or indicate what plugin/theme installed it- so, when working on WordPress, keep a shovel handy in case you have to start digging!

Ok - this write up got quite long so I reckon it counts as a case study. Crest Research is a hub for academic articles and information about security research collated by the University of Lancaster and other universities in the UK. Their old site had been running for several years on Word Press. There was a lot of content that wasn't brilliantly organised and there was lots of plugins that had been added to WP (honestly one of the things I like least about WP is that it's too easy for users to add plugins without really understanding the implications). We persuaded the University that it would be much better to make the move to Processwire. No small part of that was being able to demonstrate that PW was a much better option from a security point of view. We also wanted to be able to develop an API that provides content to a native app we built for Crest a while back; that probably would have been doable in WP but much easier in PW. This was our first reasonably large move from WP to PW so we learnt a lot on the way. So - first step was to import all of the posts from WP. For this we headed to Adrian's ProcessMigrator module which worked well at getting the data over. Once we had the data over we used Wanze's ProcessBatcher module to do bulk updates and moves to try and organise things (including deleting a load of WP tags we didn't want to keep). We found that we needed import certain things manually as well, in particular some thumbnail images. For these we just created an import script that read through a CSV of data that we'd dumped from the WP database. Honestly PW is just great at this - we had a column of page aliases and a column of image URLs and with about 10 lines of code we manged to download the images and add them to our imported pages. We've used this method of a CSV and an import script on a couple of other projects where we've needed to load content from other platforms and it's been very straightforward and effective. Once we had the content over there were a couple of other bits of functionality from the WP site that needed to replicate. One of these was a download manager. The old site kept statistics of the number of file downloads which we needed to replicate (and retain the old data) so we built a modue to handle that. This was pretty much our first foray into PW module development and Bernhard's blog on building admin modules was very useful. We tried to remove as many WP short codes as possible but those we need to keep we replicated in the Hanna Code module. The search on the new site was very important to the client - a lot of their targe audience is researchers and academics. We ended up with a system of filters (author, tag etc) together with the text matching operators that appeared in 3.0.160. The client also asked if we could add some kind of fuzzy searching for misspelled words and US / UK spelling differences which we did by adding to the lemmas in Ryan's WireWordTools module. Our additions our available on GitHub. I think there's still plenty of refining to do on the search but it works well. Another thing the client asked for was an indication of 'Reading Time' for an article as Medium have on their articles. We added a hook to calculate the reading time for an article when the page is saved. Can't seem to find the blogpost on Medium where they explained their formula but I've stuck the code we ended up with up on GitHub as a gist here. Other modules we used include: AIOM+ - this was before we got a license for ProCache. We used AIOM and then some hooks to generate cached versions of some chunks of html using MarkupCache. Probably wouldn't bother now and just use ProCache. Redirects - we tried to keep the site structure the same as the old site for SEO, but there was quite a lot of organising. We grabbed the top few hundred pages from Google Analytics and then ran those through a PHP script to check their status on the dev site (gist of that script on GitHub as well ). We dumped those results into a spreadsheet and decided where they needed to be directed to. Then we imported that list back in the Redirects module. Other honourable mentions go to Connect Page Fields, Page Field Edit Links, Dashboard, Schedule Pages and of course Tracy Debugger (which was particularly useful on this project). So... I'm sure you're asking (assuming anyone has made it this far) what the end site was like and whether the client was happy? Well comparing the old and new sites in Lighthouse gave us this: And Mozilla Observatory gave these rather nice results (especially since it's a security focused site) This resulted in a big upswing in traffic. We're seeing about a 500% increase in vistors compared to this time last year (and from pretty good numbers in the first place). IMO the biggest factor in this increase was the improved page speeds. Now - of course we probably could have got similar results in WordPress if we'd spent enough time and energy on the site but by using PW we've ended up with a much cleaner site which the client is happy to use. Logging into the old site with it's upselling of plugins and so on is just painful. We've also educated the client as to why adding random plugins is not a good thing; the old site loaded 18 javascript files from various sites most of which we didn't know anything about - we have 3 now (and one of those is analytics which we tried to persuade them to lose.). Anyway - they're happy and we've got plans to keep developing the site over the next couple of years so hopefully it's just going to keep getting better. s.