Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 03/10/2019 in all areas

  1. Glad you like the updates! Hope I didn't give the wrong impression, as I didn't intend to communicate anything about a "feature freeze" (as was stated in one of the messages above). At least nothing like that was, is, or ever will be planned, except maybe for a few days prior to a master version release. This is a stable project, but not a static one. There is no freezing or thawing, just the flow—I'll try to clarify... ProcessWire was originally built out of the needs of web development projects here, and that has always been a significant driver of what and when features are focused on at any point in time. When I add or improve something, it's usually because I'm going to be using it now and always going forward in actual projects, and by extension, can also support it in this project for everyone else. Of course, I only add/improve stuff that I know has significant benefit for all PW users, regardless of whether it's recognized in the short term or not. The other major part is features that arise from needs or contributions in the community here and on GitHub. My client projects are pretty similar to those of most PW users, which is good for the project. I'm always looking for ways to optimize and improve PW and its API, especially things that will save time in my and your projects, and this has always been the case. I'm driven by it. The feature focus is always holistic and never sacrifices backwards compatibility. And the product focus is on long term quality and sustainability, being the best tool for the job, not on being popular. The focus may largely be on issue reports right now, but this should not be interpreted to mean anything beyond resolving issue reports. I'm making continuous improvements and additions where appropriate along the way, as always. Perhaps they aren't big enough things to warrant blog posts now, but stay tuned — there is lots of good stuff on the way and currently in development. Every year there are a couple of important periods of good momentum in the issues repo, especially this time around, and so I'd like to continue that as long as possible and hopefully cover everything there. The difference this time is that we've got Netcarver expertly leading the effort as well as intelligently identifying which reports are still relevant. Plus there are a whole lot more "includes suggested fix" reports this time, thanks to people like Toutouwai and many others that know their way around the core extremely well, and often figure out how to resolve issues well before I do. It's a great community collaboration.
    9 points
  2. Just a quick update this week rather than a blog post. I’ve been continuing to work through the PW issues repo with Netcarver and it seems to be working well, so am planning to just keep working through it till we’ve covered everything there. Thanks to Netcarver and everyone else helping there. When we get the issues repo to the point where it’s pretty empty, I thought we’d then move on to the requests repo and PRs if possible. While there have been several commits to the core this week (mostly related to the issues repo), I don’t think there’s anything major enough to warrant a version bump, so will get another week’s worth of updates in place before bumping it to the next version number. This week I’ve been putting the finishing touches on the ProMailer module, getting that ready for release. A copy of ProMailer will be available to current subscribers of the ProDevTools package that want it. A few people have indicated that they’d also like to see it as a product independent of the ProDevTools, and actually I think that makes sense because ProMailer has become a much more comprehensive product than originally planned, and it really needs its own dedicated support board, as well as dedicated dev and agency versions. So I will make those available separately from ProDevTools. If you are a current ProDevTools subscriber and you’d like to get the first version of ProMailer when it is ready, please send me a PM here in the forums indicating that, and I will get a copy to you when it is released in beta. Even if you aren’t a ProDevTools subscriber, but would still like to be notified when ProMailer is available, please send me a PM as well. If all goes well, it should be available by this time next week or earlier. Next month we’ll hopefully be back to work on the website here as well, and develop the new modules directory.
    5 points
  3. In addition to Ryan's work in the codebase, I'd like to mention @matjazp, @Robin S and @adrian for their activity in the issue repo! (I know there are others - but these three stand out to me.) Six weeks ago there were 230+ open issues, we just dipped under 100.
    4 points
  4. Hello @kongondo I have implemented some changes to the navbar/menu: If you like it I can make a PR. What do you think?
    3 points
  5. GitHub Pull Requests in Visual Studio Code How on earth did I/we miss this one?! Reviewing, creating, approving, commenting on and testing GitHub Pull Requests right inside VS Code! Introduction to the extension Creating PRs Marketplace I think this is pretty amazing! ?
    3 points
  6. I never had problems with multilang install... but I'm using Laragon locally. The above error or warning message is somewhat misleading. Don't ever edit files inside wire/. What you should do instead, is go to setup > languages and then spot the according JSON file to translate, e.g. http://localhost/pw/admin/setup/language-translator/edit/?language_id=1012&textdomain=wire--modules--languagesupport--languagesupport-module (or are these underlined strings direct links to these settings?) In my case, the locale was already there. However, I don't think this is the reason why you get these strange 404 errors. Did you install one profile after another in the same directory? Maybe there are some leftovers from previous profiles / installs. Check the .htaccess file. Maybe you need to adjust some settings there. Maybe delete everything inside site/assets/cache/ folder, delete your browser cookies, log out of admin, and retry.
    2 points
  7. Another way this could be done is via the following "Selector string" for "Selectable pages" for the Categories field: template=category, has_parent=page.rootParent
    2 points
  8. See the Page class (/wire/core/Page.php), especially the static array $baseProperties. For children, see this line. The magic itself happens in the method get(). For children(), this line, i.e.: // snip else if($type === 'm') { // local method return $this->{$key}();// magic :-)
    2 points
  9. Great works guys! Thanks @netcarver and his "crew" @matjazp @adrian and @Robin S.
    2 points
  10. This module is improved and extended successor to Version Control For Text Fields. It handles everything it's predecessor did -- providing basic version control features for page content -- and quite a bit more. Download or clone from GitHub: https://github.com/teppokoivula/VersionControl. This module requires ProcessWire 2.4.1 or later, mostly because of the file features, which require certain Pagefile and Pageimage methods to be hookable. There's no sensible way around this limitation; for those stuck with < 2.4.1, Version Control For Text Fields will remain a viable option. What does it do? While editing pages, fields with old revisions available show up with a new icon in their header bars. By hovering that icon you get a list of available revisions and by clicking any one of those the value of that particular field is reverted to that revision. No changes are made to page until you choose a revision and save the page, which means that you can keep switching between revisions to get an idea what's really changed without inadvertently causing any content to change. The module also adds a History tab to page edit. This tab opens a view to the history of current page in the form of "revisions" -- each of which is a group of changes to page fields processed during one page save (similar to revisions in various source control applications). There are three actions you can perform on these revisions: adding comments, live previewing what the page might've looked in that revision and restoring the page to specific revision. One specific feature that has been a big thing for me personally is support for file (and image) fields, as the original version control module felt rather incomplete without it. I'm hoping to take this a lot further performance, stability and feature wise, but as it stands right now, it's already included here and should be fully functional. Watch the video preview here I prepared a little screencast outlining most of this: http://youtu.be/AkEt3W7meic. Considering that it was my first screencast ever, I'd like to think that it wasn't that bad.. but I might give it another shot at some point, this time planning a bit before hitting "record" Upgrading from Version Control For Text Fields For those already using Version Control For Text Fields, I've added something extra. If you upgrade that module to it's latest version, you should see a new checkbox in it's settings screen saying "Don't drop tables during uninstall". If you check this, uninstall the module and then remove it's files (this is required in order to install Version Control), your old data should be automagically imported to Version Control. Import has only been tested with limited amounts of demo data. Proper tests are yet to come, so please be careful with this feature! Update, 21.6.2015: as of today, this module is no longer in beta. While all the regular warnings still apply (making changes, including installing any new modules, on a production site should always be considered risky) Version Control has gone through pretty extensive testing, and should be as stable as any other module out there.
    1 point
  11. Hello, this module can publish content of a Processwire page on a Facebook page, triggered by saving the Processwire page. To set it up, configure the module with a Facebook app ID, secret and a Page ID. Following is additional configuration on Facebook for developers: Minimum Required Facebook App configuration: on Settings -> Basics, provide the App Domains, provide the Site URL, on Settings -> Advanced, set the API version (has been tested up to v3.3), add Product: Facebook Login, on Facebook Login -> Settings, set Client OAuth Login: Yes, set Web OAuth Login: Yes, set Enforce HTTPS: Yes, add "https://www.example.com/processwire/page/" to field Valid OAuth Redirect URIs. This module is configurable as follows: Templates: posts can take place only for pages with the defined templates. On/Off switch: specify a checkbox field that will not allow the post if checked. Specify a message and/or an image for the post. Usage edit the desired PW page and save; it will post right after the initial Facebook log in and permission granting. After that, an access token is kept. Download PW module directory: http://modules.processwire.com/modules/auto-fb-post/ Github: https://github.com/kastrind/AutoFbPost Note: Facebook SDK for PHP is utilized.
    1 point
  12. WIP module (90% done) following this request expression of interest ? by @szabesz. A (Process) module that allows the posting of Notes in the ProcessWire admin. Inspired by WP Dashboard Notes (see video in link above). The module is almost complete. As usual, I hit a snag with the CSS! PRs highly welcome, please! (see below). Setting note sizes and display was a bit tricky. Module is now available for alpha testing here. https://github.com/kongondo/DashboardNotes Contributing I should have mentioned this earlier and done it properly but I am lazy, so this is the rough guide. I know we all have our preferences but please note: No heredoc syntax No alternative syntax for control structures (i.e. endif, etc) Indent using tabs (4) Doesn't matter in this case, but no PHP short tags For methods, opening curly bracket on same line as the method name (there's a technical wording for this, I can't remember now) Features Set Notes priority (low/normal/high) Note text and background colours Enable/disable replies to Notes Lock Notes for editing Viewing of Notes can be controlled using users IDs, roles or permissions. Default is all Notes can be viewed by all who have access to the module Edit Note after posting Global note settings (accessible only to those with dashboard-notes-settings permission) - default colours, date format, if users can delete notes they did not create, if users can edit notes they did not create, note display dimensions, maximum depth of (nested) replies, maximum characters of note preview before truncate, etc.) Sort notes by date, title or priority Pending Bulk actions (delete, lock, change priority, etc) Reply/commenting on notes More testing on visibility Requests/Ideas Mine is: PRs are welcome! Especially with the CSS and/or Design (Use the Dev Branch please) Display Note author title (if present, or any other named author title field) rather than their (user)name? Other? Screenshots Thanks!
    1 point
  13. OK! ? Sorted! ? By default devilbox uses PHP_SERVER=7.2, HTTPD_SERVER=nginx-stable and MYSQL_SERVER=mariadb-10.3 when you up the containers. This is the config in the .env file. https://devilbox.readthedocs.io/en/latest/getting-started/change-container-versions.html#change-web-server-version But it seems ProcessWire does not like either of those (to be tested which one exactly). One I changed the .env file to use PHP 7.2 alongside HTTPD_SERVER=apache-2.4 and MYSQL_SERVER=mysql-5.7 it all works 100% out of the box. Given devilbox has all the tools I need now and will need pretty soon and even more so ProcessWire is a real beauty, given it is so versatile, modular, lightweight and really just anything you want it to be I will be loving to work with it. In fact I would not even call that work, it will be tremendous fun. Just have a look at all this. https://github.com/dadish/skyscrapers-app https://medium.com/icf-church-developers/processwire-vue-js-a-lovestory-d4d5bca365 https://github.com/dadish/ProcessGraphQL And there is not even a need for a frontend framework, something these days pretty any dev jumps onto. For smaller sites something like this is just super neat. https://webdesign.tutsplus.com/tutorials/how-to-create-an-ajax-driven-theme-for-processwire--cms-26579 And for the simple things I have lined up GraphQL will/might not even be needed. But given that fact you can just take ProcessWire in the backend, do anything you like with it and are then totally free in the frontend, well that is what I already really love about it.?? p.s. Found a small typo on line 68 of the created config.php inside the /site/ dir. It is variables and not varibles. * Recommended. This enables API varibles like $pages to also be accessed as pages(),
    1 point
  14. Aaah. I see. I didn't know that.
    1 point
  15. Thanks for narrowing it down. I can't understand why the Tracy logs would be so slow, but I'll take a look and see if I can figure something out. As for "not needing" them - I would suggest reconsidering - sometimes they will capture errors that Tracy will miss for reasons related to the timing of when Tracy is loaded (I think), so seeing a red icon for one/both of these can highlight the reason for an error you might otherwise be confused about.
    1 point
  16. Definitely Tracy Logs and to some extent ProcessWire Logs. I enabled all panels , disabling them one by one to reach this conclusion. Deleting ProcessWire Logs did not help. Deleting Tracy Logs resolved the issue. For now, I've just disabled both logs since I don't need them. Thanks again!
    1 point
  17. Seems we posted same time. I didn't have any custom panels enabled. Disabling panels and leaving a few (see my post above) seems to have resolved the issue. This wasn't enabled. I use it sometimes. I have now enabled it and page loads (front and back) are still fast. I did this before I posted my issue and it did not resolve the issue. 7.2
    1 point
  18. @kongondo Yes. Disable modules in the Tracy console, especially Tracy and ProcessWire logs. I experienced the same on one site of mine. You can see the load times in the Tracy panel
    1 point
  19. Thx, I'll do so ? Links are still working for me and I'm using them a lot ?
    1 point
  20. Hey @tpr - let me think about this and I'll follow up on your PM with your other idea. @bernhard - probably best to request that as a core feature. On the issue of linking to your code editor, I've just noticed that VSCode links are no longer working for me - not sure if it's a VSCode update that broke something or what. Are they still working for you?
    1 point
  21. Hey @szabesz, thank you for this hint. I did not know about @adrian's module. Finally I got time to install it and look into the code. I really like that it also cares for limiting view- and editing-rights in the backend, what PageAccessReleasetime currently doesn't. But it could be a useful feature for PageAccessReleasetime as well. In the current version every backend-user can see unreleased pages in the pagetree. I don't like that the module deals with the HTML shown in the frontend if a user cannot access a page. PageAccessReleasetime instead throws a 404 exception, what can be acceptable for the releasetime context. If I think of a PageAccessUserrole-module, it would be better to throw a 401 exception that leads to a custom 401 page where a login-form is shown. But ProcessWire seems not to support other exception pages than 404 and there is no other core exception class than Wire404Exception. Let me know if you have a practical solution for it, where my module does not have to generate its own HTML for the error page. I think that is something that the template-developer should be aware of and not the module.
    1 point
  22. My pleasure ? Done. All three commits are in the first PR.
    1 point
  23. sure, but after editing the first, the warning went away... ?
    1 point
  24. Yes, they are ? @Autofahrn this might also be a hint for you ?
    1 point
  25. It looks absolutely awesome! Please send the PR. i'll review it together with the others you've already made. Thanks!
    1 point
  26. Hey @adrian, would it be possible to make those logs linked to the file + line just like it is in the debug bar? It would be great to not only see the log of the call stack but also just click on the line and jump there in your IDE. Or is this a feature request for the tracy core and should be addressed to nette? thx
    1 point
  27. HTML Purifier is not yet configurable in ProcessWire. You can give this request a thumb's up though: https://github.com/processwire/processwire-requests/issues/226 Anyway, without being able to actually configure it I have no experience in this field.
    1 point
  28. @psy, all resolved. Now working beautifully thank you @psy! Make sure, if you recreate your website entry on the PushAlert site you download a FRESH copy of the manifest.json & sw.js (oh dear, I thought I had!). The PushAlert support team were super fast & very friendly if you run in to any problems. Thank you PushAlert.
    1 point
  29. You were right. I tried the HTMLPurifier Demo and it removes the button html: http://htmlpurifier.org/demo.php Strange, that it doesn't like buttons.
    1 point
  30. Hello, this module has been updated to conform to recent Facebook regulations that won't allow publishing content on a user profile. Instead, a post may be published on a Facebook page by the Facebook page only. To set it up, configure the module with a Facebook app ID, secret and a Page ID. Following is additional configuration on Facebook for developers: Minimum Required Facebook App configuration: on Settings -> Basics, provide the App Domains, provide the Site URL, on Settings -> Advanced, set the API version (has been tested up to v3.3), add Product: Facebook Login, on Facebook Login -> Settings, set Client OAuth Login: Yes, set Web OAuth Login: Yes, set Enforce HTTPS: Yes, add "https://www.example.com/processwire/page/" to field Valid OAuth Redirect URIs.  You may also view the revised first post of this topic. Thank you for your valuable input and I hope this update helps! Kind regards, Dimitrios
    1 point
  31. Welcome to ProcessWire and the forums @Re4DeR. Something like below added in /site/ready.php should do the trick. If you don't have a ready.php file, just create one and namespace it to ProcessWire; $wire->addHookAfter('InputfieldPage::getSelectablePages', function($event) { if($event->object->hasField == 'categories') { $sitePage = $event->arguments('page')->rootParent; $siteCategories = $sitePage->child('template=categories')->children; if($siteCategories->count()) { $event->return = $siteCategories; } } }); With the above code, individual posts in Site 1 will only be able to select categories from Site 1 and for Site 2, they'll only be able to select from their site. Please note: The page (reference) field is called categories The template of the 2 Categories pages (i.e. the parents of your individual categories) is called categories. In the page field categories, we don't input anything in the Selectable pages section. Give us a shout if you have any questions.
    1 point
  32. Welcome to the forums and ProcessWire ?. ProcessWire does this only once. So, the next time, it will just load the thumbnail you requested, hence it is permanent unless you delete it. I think you mean 0x260. That is generated automatically by ProcessWire for backend use. You can create your own (other sizes) like shown below. This code goes into your template file. // Example of outputting a thumbnail gallery of Pageimage objects foreach($page->images as $image) { // $image and $thumb are both Pageimage objects $thumb = $image->size(250, 200);// width x height echo "<a href='$image->url'>"; echo "<img src='$thumb->url' alt='$image->description' />"; echo "</a>"; } You can use the above code to create the thumbnails outside a page load if you wish. Have a look at the docs here: https://processwire.com/api/ref/pageimage/
    1 point
×
×
  • Create New...