Leaderboard

ProcessWire 3.0.181 has fixes and improvements as usual, but the biggest addition is a nice pull request from @LostKobrakai, plus major updates to our Helloworld and ProcessHello demonstration modules. This post covers it all— https://processwire.com/blog/posts/pw-3.0.181-hello/

I've got some core updates in progress but nothing major committed yet, so we'll save that for next week. But I wanted to briefly tell you about a module I'm working on here, which I plan to eventually put in core. I built it for some needs I've had here, but it will first be released in ProDrafts (so ProDrafts may start using its API), and in ProDevTools too, since it is also a developer tool. It's a snapshot versioning system for pages, but more of an API tool at this stage, kind of like the $pages API var, but for snapshots/versions of pages. It lets you create a snapshot of any page, including its fields and files (including core fields, ProFields, 3rd party fields, repeaters, nested repeaters, table fields with a million rows, etc.). The snapshots can be restored at any later time. Snapshots may also be restored to a different page, such as a new or existing page. In this manner, a module like ProDrafts may be able to use it to manage draft versions even better than it currently can, or at least that's the plan. Though since it's an API tool, my hope is that when/if it winds up in the core, others may be able to use it for stuff we've not thought of yet too. The module is a little different than my previous attempts (like what's in ProDrafts now) in that it does most of its work directly at the database level (and file system level, where applicable), which enables it work without needing to know much about the Fieldtype. Currently it is fully functional, but I have a few less common cases to work out before it's ready for release. Once installed, every page includes a Snapshots fieldset, which can be located in the settings tab of the page editor, or a separate tab in the page editor (configurable). When installed, every page has one, so long as the user has the appropriate permissions. There's a screenshot of what it looks like in the page editor below, but it is very simple at this stage, basically just enough for testing purposes. Every snapshot has a name that is unique on the page. You can overwrite a snapshot just by saving a snapshot with the same name on the same page. So you could for instance have a hook that creates a snapshot named "undo" right before a page is saved (in a Pages::saveReady hook), and in that way a module could add a basic undo capability to the page editor. This is just a simple example though. Thanks for reading, have a great weekend!

Just in case it gets worse: https://processwire.com/blog/posts/optimizing-404s-in-processwire/

You should inspect what the bots tried to find. Maybe this will shed some light? You can use the jumplinks module for this, for example.

The Module Blog for ProcessWire replicates and extends the popular Blog Profile. Blog is now in version 2. Please read the README in the Github link below in its entirety before using this module As of 20 December 2017 ProcessWire versions earlier than 3.x are not supported Blog Documentation is here (Work in Progress!) See this post for new features in version 2 or the readme in GitHub. To upgrade from version 1, see these instructions. ################################################## Most of the text below refers to Blog version 1 (left here for posterity). Blog version 1 consists of two modules: ProcessBlog: Manage Blog in the backend/Admin. MarkupBlog: Display Blog in the frontend. Being a module, Blog can be installed in both fresh and existing sites. Note, however, that presently, ProcessBlog is not compatible with existing installs of the Blog Profile. This is because of various structural and naming differences in respect of Fields, Templates, Template Files and Pages. If there is demand for such compatibility, I will code a separate version for managing Blog Profile installs. In order to use the 'Recent Tweets Widget', you will need to separately install and setup the module 'MarkupTwitterFeed'. Please read the README in the Github link below in its entirety before using this module (especially the bit about the Pages, etc. created by the module). I'll appreciate Beta testers, thanks! Stable release works fine. Download Modules Directory: http://modules.processwire.com/modules/process-blog/ Github: https://github.com/kongondo/Blog You can also install from right within your ProcessWire install. Screenshots (Blog version 1) Video Demos ProcessBlog MarkupBlog Credits Ryan Cramer The Alpha Testers and 'Critics' License GPL2

Wow... Thank you so much @Cybermano! That helped a lot and gave a good insight, ways, options, and things the module can do. Next step for me will be... playing around with it as there is quite a lot to play with.

Perfect! Cheers @horst Jumplinks looks to be perfect for monitoring it. If it's anything of interest, I'll report back. Otherwise thankyou and have a good evening!

I think it can be done with language alternate fields.

That's a much better idea, thanks @Robin S ? I have nearly got it working. My only issue is in the ProcessPageEdit::buildForm hook, how do I get the current page so I can match to my selector? I.e. how do I get to $page from here: \Processwire\wire('pages')->addHookAfter('ProcessPageEdit::buildForm', function(\Processwire\HookEvent $event) use($selector) { $form = $event->arguments(0); // ... $form is of type ProcessWire\InputfieldForm. How can I get to the $page being edited from that? Once I get this I can post the full working code. Thanks.

Working great! Thanks

Not sure if it's just a forum typo but you should only have quotes around the key - it should be: $page->save(['noHooks' => true]); It seems to be working here for me. The PhpDoc comments form the basis of the online documentation: https://processwire.com/api/ref/pages/save/ So you're right that it wouldn't be hard to miss but it's not buried in the sense that you'd only find it by examining the core files. As a general thing, if you call any hookable method and include the underscores at the start of the method name then any hooks to that method won't be triggered. So I think the idea here is that the noHooks option takes care of making sure that several potential downstream hooks wont fire (e.g. Pages::saveReady, Pages::savePageOrFieldReady, Pages::saved, Pages::savedPageOrField, Pages::added) but in case Pages::save was itself hooked you'd need to call it with the underscores to prevent that hook from firing. But what's interesting is that the core itself doesn't call Pages::___save (with the underscores) when you do call Page::save() with the noHooks option true, and likewise with Pages::___saveField. Maybe the documentation for the noHooks option should be expanded to explain exactly which hooks are avoided, or the core should call Pages::___save and Pages::___saveField with underscores when noHooks is true. @ryan?

I don't work with webflow, but I don't think you can call an API from the webflow server. You could probably call it from AJAX, but that wouldn't make much sense for the whole website. It seems to me that you have two options: Build the site in webflow and export the html to use in ProcessWire, or use their API to sync data between ProcessWire and their CMS. Honestly, both options seem expensive to me, since you won't be taking full advantage of the system.

Hi wbmnfktr, Don't worry, you didn't offend me ? : maybe I could be too verbose and not clear. First of all, this module doesn't install a kind of "tool" that manages food allergens in an automatic way. It moved from a need of this kind. Let's me explain better, if I can. Admin editors (webmaster or their clients too) may need to check recursively some data when edit lot of pages, e.g. inserting allergens in food menu (for each dish). So I thinked to a kind of "post-it" (or a sticky note) to check when I need to edit a page: for example, I'm not a chef nor a restaurant manager and I don't know by heart all the food allergens. So, for many clients that asked to us to maintain web editing and data entry, I built an admin page where I can check the list of allergens. But this slows down the editing process, because the page is loaded as a new page (or it could be loaded as a new tab, switching between it and the page that I'm editing). With the help of many people here, I have developed this module do build a system of "links" that they make appear a "panel" or a "modal" with the list of allergens. Obviously, you must have already setted all your fields, templates and logics. In my case, we have Hanna Code shortcuts to put into "Allergens" field, into a "menu repeater", that will be rendered as a button with tooltip. My Hanna Code item, in this case, is : <button type="button" class="btn btn-sm btn-warning rounded" data-container="body" data-html="true" data-toggle="popover" data-placement="top" data-content="<strong>Mustard</strong> and foods containing mustard."> 10 </button> In other way, you can set a SelectOptions field with Checkboxes: The code logics to display these buttons could be very similar, it doesn't matter. Here comes the help of my module: you can set where to insert the link to the list (e.g. the notes of the "allergens" field, or a sticky button that follow your scrolling). So you can limit the visibility of the link only to specific template, pages, and/or fields. Ad you don't have to open new tab or switching between them: it's available immediately. It helps me very much and speeds up my workflow for data entry. 07-CustomNotes-lr.m4v But this is not only for List of Allergens, of course. You could embed video (with the powerful tool of Video Emebed TextFormatter) , pdf manuals (just insert a link with target="_self", and it will be displayed into the panel or modal windows. In the second case it will be displayed into the whole modal like a "preview", very useful...), and other stuff. Let's think about technical manuals, videotutorials and text abstracts: pdf-docs.mp4.0a806606f78dcd86cecfe22f074c0b80.mp4 All you need to do, it's simply edit the CKEditor textarea into the settings of the module, as you do for each page that you edit. Then you will find a "reminder" where you would to see it. I hope I have explained better the use of this module to you and maybe to everybody that would try it. Now I will upload the upgrades with the corrections of @teppo .

New version released. Fixed issue when translating larger volumes of text. In testing I was successful in translating over 20,000+ words in one field. When you get to large volumes of content like that there is a very noticeable amount of time it takes to complete that request, but it does it. Download the newest alpha here: Fluency 0.3.2 This should solve your issues @B3ta, let me know if you experience any issues.

Not a response to your code, but more a general suggestion... If the point of this is to restrict what editors can do in the PW admin then I think it would be cleaner and a better experience for editors if you focus on making the admin UI conform to your restrictions. In other words, if the user may not change a page's name or template then don't show those fields in Page Edit, or set them to readonly (I seem to remember that the name input needs to remain in the Page Edit form). And if the user may not sort a page then don't show the "Move" item in page lists. You should be able to achieve this with hooks to methods such as ProcessPageEdit::buildForm() and ProcessPageListActions::getActions().

HTMX is quite good. $config->ajax won't detect HTMX requests though, so I recommend adding this to your /site/ready.php: // if htmx request, DO NOT use _main.php if(array_key_exists('HTTP_HX_REQUEST', $_SERVER)) { $config->appendTemplateFile = ''; $config->htmxRequest = true; } That assumes you are using the Markup Regions output strategy by the way. Use $config->htmxRequest as needed.

@gornycreative, me and @fliwire are not teaching you how to do your modals. Both Unpoly and htmx are js libraries that help you (amoung other things) to extract a portion of markup that they receive from a ajax requests and paste it where you want it (in a modal). That way you do not need to alter the rendering, but can define which part of a rendered markup you need.

@thetuningspoon It doesn't have anything related to that, but that example you mentioned could easily be accommodated with a hook to Pages::clone. Or maybe it's something that should be built into FieldtypeTextarea’s link abstraction. @Ivan Gretsky Yes it definitely has the API for that sort of thing. @markus_blue_tomato Yes it does include the $page->meta() data by default, but you can specify an option to exclude it when/if you want to.

There is no variable value in this module's API. The page id is at the variable info. So: <? php $pageReferencedByMarker = $pages->get((int) $dot->info); // do something with $pageReferencedByMarker

Blog 2 is now on dev branch of the project page on GitHub. I have edited post #123 and #124 with links to this effect. Version 2.0.1 is coming out soon. I picked up on some broken Markup bugs whilst testing the other day as well as some output redundancy...

Don't think this marked solution is the solution? It's very simple. First it's always nice to know what multi-language approach you use since there's multiple ways. If you use the LanguageSupport modules with LanguageSupportPageNames also installed (which I guess you use), you'd set the language segments on the home/root page. There you'll find a name for each language. Let's assume you have german default and english alternative language, you'd probably set the name to german: "de" english: "en" This will result in urls like /de/meineseite/ and /en/mypage/ Default name could also left empty, so there won't be any language segment for it and only be /meineseite/. So, but you name them "startseite" and "home" which is strange as this would result in /startseite/meineseite/ and /home/mypage/, which is not desirable I think. So taking the language segments as described before a language switch using $page->localUrl(language) will return the correct url to the language. On the homepage this would result in domain.com (always default language, unless you set option to redirect to /de/ in LanguageSupportPageNames module) domain.com/de/ domain.com/en/ The language is always evaluated from the requested URL, and $page->url will always return urls of a page according the current language. You can get a localized url of a page explicit with $page->localUrl(language).