Search the Community

Part 1 of a 2 part Module & Service Reveal. I'm currently working on a new module: ModuleReleaseNotes that was inspired by the work I originally did on making Ryan's ProcessWireUpgrades module "release" aware. In the end, I decided to ditch the approach I was originally taking and instead work on a module that hooked in to the UpgradeConfirmation dialog and the module edit page. Aims My aims for this module are as follows... Make discovery of a module's changes prior to an upgrade a trivial task. Make breaking changes very obvious. Make reading of a module's support documentation post-install a trivial task. Make module authors start to think about how they can improve the change discovery process for their modules. Make sure the display of information from the module support files/commit messages doesn't introduce a vulnerability. Looking at these in turn... Making discovery of a module's changes prior to upgrade a trivial task. This is done by adding a "What's changed section" to the upgrade confirmation dialog. This section takes a best-effort approach to showing what's changed between the installed version and the updated version that's available via the module repository. At present, it is only able to talk to github-hosted repositories in order to ask them for the release notes, the changelog file (if present) and a list of commits between the git tag that matches the installed version and the tag matching the latest version. It will display the Release Notes (if the author is using the feature), else it will display the commits between the tags (if tagging is used by the module author) else it will show the changelog file (if present) else it will show the latest N commits on the master branch (N, of course, being configurable to your liking.) An example of the Github Release Notes pulled in for you, taken from Mike Rockett's TextformatterTypographer Module... An example of a tag-to-tag commit list from the same module... An example of a changelog - formatted to show just the changes (formatting styles will change)... Finally, an example of a fallback list of commits - sorry Adrian ... Making breaking changes obvious. This is currently done by searching for a set of configurable search strings. Later versions may be able to support breaking change detection via use of Semantic Versioning - but this may require some way of signalling the use of this versioning standard on a module-by-module basis. For now, then, you can customise the default set of change markers. Here I have added my own alias to the list of breaking change markers and the changes section of the changelog is styled accordingly (these will be improved)... Make reading of a module's support documentation, post-install, a trivial task. This is done by making some of the support files (like the README, CHANGELOG and LICENSE files) readable from the module's information/settings screen. There is an option to control the initial open/closed state of this section... Here is Tracy's README file from within the module settings page... Make module authors start to think about how they can improve the change discovery process for their modules. There are notes in each of the sections displayed on the upgrade confirmation page that help authors use each of the features... Make sure display of external information doesn't introduce a vulnerability. This is an ongoing concern, and is the thing that is most likely to delay or prevent this module's release lead to this module's withdrawl should a vulnerability be found. Currently, output is formatted either via Markdown + HTML Purifier (if it was originally a Markdown file) or via htmlspecialchars() if it has come from a plaintext file. If you discover a vulnerability, please get in contact with me via the forum PM system. Ongoing... For now, I've concentrated on integration with GitHub, as most people use that platform to host their code. I know a few people are hosting their repositories with BitBucket (PWFoo comes to mind) and some with GitLab (Mike Rockett?) and I would eventually like to have adaptor implementations for these providers (and perhaps GitKraken) - but for now, GitHub rules and the other hosts are unsupported. Links Github: ModuleReleaseNotes PW Module Repository: Here

Hi all ? I made this searchable UIkit 3.x documentation site to share with everyone. The official doc is great but you can't search across the whole doc. Anyway, here is the URL: https://uikitdocs.netlify.app/ What's missing is the live examples. Perhaps some of you can contribute? Github repo link is on the website as well. Cheers

Hi usually I don't create topics until i feel they are necessary but this is really become a chore for me in development phase, The issue is the Developer Documentation; its really hard for me to get the necessary information I need. I have to go through various topics and navigate through conversations just to find what am looking for. Just today I was looking for the API for the PageField to save a page as a value and I have no luck, I feel this can increase development time to those new to Processwire. i found out there's a site called wiki.processwire.com but it's been last updated 2012 and the cheatsheet.processwire.com doesn't go indepth enough for me to understand what's going on. ADVICE: I feel we can have a documentation page where users can edit and contribute text to it gradually, there's recipe.processwire.com but its still not enough, it would cool to have something like this http://framework.zend.com/manual/current/en/index.html Forgive my rant I come from a country where electricity is not guaranteed so its a big deal for me when I have to spend alot of time looking for information. I don't mind contributing examples or if we can find ways to allow community update the wiki.processwire.com. THANKS GUY Still looking for how to use code to save a PageFieldtype with another page

Hello, I'd like to participate to a documentation about the page flow in PW. I am still a beginner and still have difficulties to see the big picture but I could help to the writing. What is the flow when a page is displayed or created ? It would be fine to draw a scheme with every stage in which one can add hooks. Something to describe the flow in time. May be it exists. page | fields | template What do you think ?

Hi Guys It would be awesome when all the resource about processwire (tutorials, docs, cheatsheet, recipes, videos, api, faq etc...) would be unified on one documentation website called "docs.processwire.com". The new site would gather infos & data from these resources: https://processwire-recipes.com/ http://processwire.tv/ https://www.pwtuts.com/ https://processwire.com/docs/ http://cheatsheet.processwire.com/ and would unified it on the final site https://docs.processwire.com. I think It is far more better to have one endpoint for all the processwire resources & wisdom then mutliple sites. This way it is far more easier to get into the processwire world and choosing processwire as the next main cms for further projects. The Documentation Site could perhaps look like this (it is just a mockup, so don't expect to much from me ):

Today I noticed the Fieldgroups class is missing from the reference, and I wasn't sure why! Does anyone know? Also, I feel like the docs would be easier to parse/navigate if the API Variables were shown alongside the class they were an instance of. Config ($config) Field Fields ($fields) Fieldgroup Fieldgroups ($fieldgroups) Fieldtype HookEvent Inputfield InputfieldWrapper MarkupPagerNav Module Modules ($modules) ... Page ($page) Pages ($pages) ... I'm also aware of the API Gen reference page (https://processwire.com/apigen/index.html), which is more robust, but a little harder to parse.

Hi Forum, I recently had a chat with a friend who was introduced to PW by me. He said: "brilliant cms, poor documentation." His comment makes me think about the cheatsheet: While we see new API methods introduced at a very fast pace, the cheatsheet doesn't seem to keep up. That's sad, because it's such a good resource. So, how can I (as a user with very limited PHP skills) help to update the cheatsheet? Is somebody skilled willing to team up with me - as kind of a supervisor - for the update tasks? Or are there any plans on behalf of the team to update the cheatsheet? Thanks!

I like and read the blog posts at processwire.com because of all the awesome updates and new features described there. But after some time I'm searching for updates I read and sometimes it's difficult to find the needed blog post again I would prefer continuous documentation updates (api, variables, options, apigen, cheatsheet...) with the new features and the needed PW version. A blog post could point us to the examples / documentation which should have be searchable and maybe tagging system. At the moment there are great examples randomly distributed inside the blog and notably the PW forums.

This Thread is opened new as it will only discuss a centralized solution! nothing more and nothing less! The quotes are coming from the former Thread which was actualy about finding Language files on Mac and had nothing to do with the actual problem of PW! In Processwire there are 2 major problems with translations when working especially with Multidomain sites in one processwire DB 1. The default can not be defined on a per site base like in other CMS with Multidomain support in one DB. i.e. the default language get's defined by the guest user but this guest user is existing only once! You can't define a guest user on a per Domain Base in a multidomain installation which is working with one DB. Solution: Instead of defining the default language by the language of the guest user it woudl be advised to have some code or dropdown or whatshowever to choose the right default language on a per site base. This can happen i.e. through code inserted in a specific site template belonging to one domain. 2. Working with translations in Processwire is a hazzle - really and it could be much much easier. We are just testing it if Weblate or Pootle could do the job and the same with the documentation to probably use readthedocs / sphinx instead. To reduce workload on the developer site and also to increase the quality of documentation and translations it is very important to be able to collaborate with others on this. Therefor a local solution (in a module or elsewhere locally) can never be the right way in terms of smoothness, economie and workflow. As we need at least 2 - 3 translations in nearly every site we are working with including the translation of documentation (especially those for editors and site admins) we will work on a solution which lateron might help to solve the problems of all. I only hope that the modules don't get cluttered up with lots of localized files now. - If this would habben than each module we are using here will have soon also translations of Thai, Khmer, Laos, Burmese, etc in it and for sure nobody in Europe would need them! Keeping things centralized on a centralized system is the much much better way for translations and documentations. This is the case if you need to run all churches from their own DB as some have german, some English, some Thai, some even Arabic as default language! And for sure we won't handle such an amount maintaining all those translations - that's why the churches would need to handle their stuff all by them selves which will end up in a chaos and finally in a no go command from those churches to use Processwire! Most of those Churches work with volunteers and are not those Mega Million Churches with Cathedrales etc. like you see often in the US. They have usually a dedicated webteam, but ours are very tiny units and need to keep costs at anabsolut minimum. The same applies to the multidomain School Servers with many school/classroom websites in them etc. 90% of them would need another default language than English and the default languages are changing depending on the location where they are. Well as pointed out above it will be a real hazzle to keep the quality of translations and the standards if there is no centralized solution in doing all the translating stuff. Updating a translation can happen by a module and should happen by a module - no question! - But instead of storing all translations inside a module it would be adviced to keep them separated and store only one language (the default language of the module - which could also be German or even Thai) inside the module. The module in the backend would than check with the translation server which new translations would be available and download those tranalations ONLY for those modules you have installed. Those translations than get storred in a separate directory where wll those translations can be managed or even be overwritten partly by a second local translation folder for only local translations. With a fall back methode it gets checked which translation is available and should be used. is the translation available in the folder for local translation yes no? If no than check in the global translation folder yes no? If no download it from the language server? yes always means = use it. And the update process would be similar but simply skipping the local translation folder. This way you can ensure that modules always have accurate and updated translations. Finally you might run that process than via a cronjob or manually - up to you! --- Translations itself will be done on Weblate or Pootle and docs (so our idea on readthedocs or a global sphinx) Module editor provides the default language (which could be any - but the language would be needed to be specified by a code - i.e. en_UK, de_CH, de_DE etc. A parser will parse the modules directory for those default language file and convert the json into mo/po for use in Pootle. With Weblate we could integrate json directly On Weblate/Pootle those files can be translated in a collaborative effort, even by none developers, but i.e. by people who are good in translating stuff - this keeps the quality high and it will reduce the workload on developer sites as they don't need to worry about the translations or even don't have to integrate them into their modules etc. Now an integrator sets up a website and defines the default and other languages. A module will now check if there are new translations available for the installed languages and they can be downloaded and stored in the site like described already above. -- Maintenance Tasks would be quite low on the site of the Weblate/Pootle Server site. The benefit of Weblate would be that they have a FREE hosted Version of webslate of OpenSource Projects - so no maintenance stuff would on PW site concerning the translation server which is great. (but we would need to change some stuff - see below) Readthedocs is very well maintained already and it is completely free! An ideal way to do documentations and meanwhile used by lots of projects and parts of projects. And of course the module which will manage the translations needs to be maintained to so that it will continue working when the core gets updated. But this would be the case anyway with any module ;-). But here we would need to manage the connection to weblate/pootle. But also here the hosted webslate solution would be the best way to go as it can parse github repos and the translations of readthedocs will be actually hosted on a github ;-) In other words it will simply work. using Pootle it woudl be a little bit more work as the Pootle server would need to be maintained as pointed out already. -- Extendibility of that idea: 1. Integrating a backend part to translate / propose translations from within PW 2. Doing the translation of strings with a local application (which than will store those localized translations in the folder for local translations, like described above.) This can already be done by a module and this module only would need to be adjusted (enhanced) to work with translatins coming from the central langauge repository. -- WEBLATE - READTHEDOCS - GITHUB We discussed it here in our Team and we think that it is the best way to go! If there are any other ideas let us know - but for sure we are not interested in a solution which will clutter up module and corefiles with all kind of translations/documentations which we won't use on our sites! And it must be a solution which allows collaboration with others to reduce workload. Readthedocs can work with transiflex but until now we can't see a better free solution than weblate or pootle http://www.oneskyapp.com/comparison/transifex-alternative/ Some links for those interested: Readthedocs (maintained and hosted) https://readthedocs.org/ Weblate (maintained and hosted) http://weblate.org https://hosted.weblate.org/ http://weblate.org/en/features/ http://weblate.org/en/hosting/ Pootle (selfhosted) http://pootle.translatehouse.org/ We propose the following way to go IMHO https://hosted.weblate.org/ + https://readthedocs.org/ + https://github.com/ Benefits: We could reuse the JSON Collaboration on translations would be available Documentation would be available for translation to The code gets already maintained on github while I suggest to open up another repo in which all modules (also those not approved meanwhile by the ryan team) could be integrated for translation and documentation. This would help to get translations and documentations done already in an earlier state than stable. If you know a better maintained and free solution like we proposed above to be used for a collaboartive translation and documentation effort, please point it out and describe the benefits of it in comparison to what we propose here. --- Important REMARK: This thread is NOT meant to discuss if there should be a centralized or only a local solution! Please keep all stuff concerning this out of that Thread and discuss it elsewhere. This Thread here is ONLY! about a globalized collaborative solution where the translations get managed at a centralized place and where documentation gets written on a centraliced place and where we create a module to integrate all those translations and documentations. Who would be interested to work with us on getting things done and to move the modules and documentation to weblate and readthedocs. PM us! Thanks.

Just a very vague idea here. The idea is to create a set of help pages in the back end. Not the wonderful notes system from Soma (which is ever useful), but a centralised system that is partly automated. So, for each module two sets of docs are written by the developer - admin and user. When a module is installed, these are automatically added to the backend help system. This is permissions based, so the superuser can decide who can see which set, plus make exceptions for specific modules. This includes switching some of the docs off entirely if it is thought they might confuse or are simply not needed. (Might even allow devs to pre set this if their mod adds functionality where docs are unlikely to be needed) Additional notes can be added manually to each of the docs at either the head or tail so the admin can add anything specific to that particular website. When modules are updated (which might include updates to their docs) these additional notes are not affected and still work. Extra docs can then be added by the admin for site specific functionality that are not related to a specific module. The entire lot can be viewed in the admin as a cohesive set or can be viewed as in context help in a popup. Sorry! This system does put a pile of work on module developers (and even more on Ryan), but the result if worked out properly could help the day to day usage of the admin enormously and makes ProcessWire even more accessible to potential clients The two sets are key here. On other systems where help is built in, it is often aimed at the admin not the user, so the poor user gets flooded with information they might not understand and do not have the permissions to use even if they do. This way, each user, admin or other, just gets the bits they need which is a lot cleaner!

Hi guys, I was going through the docs and read this: on this page The thing is wordpress no more deliver keys, so we just need to remove that part . Cya! P.S.: I was not sure where to post this topic, as it have no real impact I guessed the pub talk was fine. But if you have a suggestion for the next time, I'm all ears.

I have just dipped my toe into the large space that is the ProcessWire wiki. At the moment, that just means that I have just logged on and am just creating a couple of templates and some other bits and pieces - nothing complicated, I don't have enough time! Once I have done that, I will start scribbling. For the moment, all I have done is a half complete help page about starting a new article (click on help in the left navigation), and created two categories - Drafts and Pending. Hopefully this will help with anything anyone writes which they want to flag up as not finished or need checking. More info on the help page. Talking of categories - if someone has any good ideas about what categories should be created and how they should be organised - that would be really useful! Joss. (PS: If anyone needs a logon for the Wiki, please ask Ryan, not me!)

Hi ProcessWire'ers, I'm a total newb, reading through the docs to try and get up to speed with PW. I read here that: But if I visit Admin > setup > templates then Edit > Advanced, I see no reference to URL Segments. Any comments on why would be most appreciated, cheers, -Alan