Leaderboard

The weakest point of WordPress has always been not relying on well established design patterns but on custom, ad-hoc solutions they made up as they went. Also, there is a great belief in not starting from scratch but trying to refactor the whole system somehow to get rid fo the technical debt, even thought it rarely succeeds, if ever. Maybe it might work for small projects but not for substantial ones. The devs of WordPress certainly failed in that. Another team trying to make a gradual but complete refactoring to make this idea come true is the devs of PrestaShop. They advertise it as the only sensible way to go, as this way – according to their reasoning – merchants can keep their investments in paid modules and other customizations applied to their shop(s), yet, when the next major PrestaShop version upgrade comes along, merchants are expected to start from scratch, somehow importing their old (and "incompatible") shop data into a freshly installed PrestaShop! They also state that module developers can better support their modules because they can keep them compatible with several mayor versions of PrestaShop without writing and maintaining their modules for each major versions separately. However, the the thing is that they do it by writing extremely long if-else statements all over the place to take account into all the differences between the systems (and there are many!), so you can imagine how fragile that style of coding is. Does that really help the module developers? I don't think so. ProcessWire used to have a v1 version and Ryan decided to start from scratch, and there must have been a good reason behind it. When something fails to deliver what it was supposed to deliver, then – in the long run – the only way to move forward is it to go back to square one. Two more "success stories" regarding starting form the "beginning": Ashley Hewson's interview : https://youtu.be/ABM60-0fbuM?t=344 Construct: https://www.construct.net/en/about Even Adobe has failed in this regard, as their applications are just somewhat similar to each other and they are still not yet rewritten, they just keep growing in size, never really bringing real UX enchantments along they way by turning into one, actually integrated suite like the Affinity apps. I have already switched from InDesign and Illustrator to Publisher and Designer. Affinity Photo has yet to deliver smart objects and pixel wrapping so that I can leave Photoshop as well, but I hope they are already working on these features. Fingers crossed ? Sorry for partially being off-topic.

I've been following WP's Block Editor development on-and-off since it was announced. I was hoping for the best and something very well thought out given they could make core changes to WordPress to facilitate a great experience, but it seems, at least from my point of view, chaotic and disjointed. I am not surprised however since page builders are tough to do, especially if certain things are not "forced" (like a universal CSS framework). This comment touches upon several issues from a developer's point of view: https://wptavern.com/getting-to-know-the-upcoming-wordpress-5-8-template-editor#comment-382930

Thank you @teppo! ? https://weekly.pw/issue/371/

This might be some kind of an unpopular opinion but... ProcessWire gets even better while reading the docs, recreate all tutorials available, and through repeating each and every step from installation to writing a hook within a module. That's how I started to love ProcessWire - coming from Textpattern with a background in Drupal, Wordpress and other CMSs. I'm everything but a programmer, coder or developer... still I can do so many things I always wanted and needed to do. My very first project (2014/2015) with ProcessWire was awesome back in the days. It had so many features, functions, options, and what-ever... yet... looking into the code today... I was a foolish guy back in the days. Yet the project is still alive, running, and the client is happy as ever. You will grow with each and every project, while reading in the forum. Yes... reading each and every post here (top right corner: unread; thats a nice link you might want to add as your starting page) will help you so much. I'm into ProcessWire for quite a long time... yet I find so many things it can do... without even knowing. To be fair... you are right... the community here is way more than awesome than anywhere else! IMO* Final words to this loose rambling... Welcome to ProcessWire! * IMO

Thank you all for your answers and insight! The more I look at ProcessWire the more I like what I see, and I appreciate you all clearing up my question for me. I'm looking forward to continue experimenting with this system, but honestly one of the biggest things I love about this so far is the community. Good documentation and ability to get questions answered is a big deal for me. So far I love how extensive ProcessWire's documentation is, and I thank you all for the warm welcomes!

Hey @benbyf... I don't know if it's working now within your project... so I'll make it short: The module is working perfectly fine in my setup which is 10 minutes old and is running on PW 3.0.179. I just created an API key, limited it to just sending mails, put it in the module config and everything was fine - almost. The sandbox option prevents sending mails so it needs to be removed. I don't use any of the other options within the module expect logging. SendGrid tells you your usage (you fill find that link in the bottom of the sidebar) so you can check if something was sent. Another option is of course this gem here: https://processwire-recipes.com/recipes/logging-outgoing-emails/ (which is in place as well and logged all of my test mails).

Out of the box, ProcessWire’s “Add Page” functionality is a two-step process: 1. Specify a page title 2. Populate the page Although there are use cases where you wish you don’t have to direct your content editors to specify a title. So it would be great if we can have some settings in the template where we can set a default title and name “on create” and expose OOTB page properties as tokens like %id%, %createdDate%, and so on.

Thanks, I think there was several things, I hadn't verifed the email account properly, I found the PW logs and sorted it out, then found that sendgrid simply isn't logging anything, not a peep... emails are getting sent so i suppose it just takes a while to register on their stats or something but its really strange.

Soooo true! In consequence, devs have to follow that and do the same. We have so many WordPress sites which have grown in years and and now they are stupidly patched with our homegrown snippets, patches, hooks, etc. And lots of them have been frozen against updates because of incompatibilities or/and Gutenberg. The only option is to build such a site from the beginning. In some cases we did. The same. I get the idea. I just don't buy the WP way from the very beginning. After 3 years of Gutenberg it doesn't get any better. And this is an opinion of our clients/administrators. I've never liked it so I'm not objective here.

Hi @Orkun // For view actions urls and all url for the pages wire()->addHookAfter("Page(template=post)::path, Page(template=post)::localHttpUrl, Page(template=post)::localUrl, Page(template=post)::localPath", function($e) { $page = $e->object; $pages = wire('pages'); $user = wire('user'); $language = $user->language; $langSegment = $pages->get("/")->localPath($language); $pageName = $page->localName($language, true); $e->return = $langSegment . "$pageName/"; }); // this hook is needed to change parent path so we can get right url in link above page name field wire()->addHookBefore("InputfieldPageName::render", function($e) { $inputfield = $e->object; $parentPageID = $inputfield->parentPage->id; $hookId = wire()->addHookAfter("Page(id=$parentPageID)::path", function($e) { $pages = wire('pages'); $user = wire('user'); $language = $user->language; $langSegment = $pages->get("/")->localPath($language); $e->return = $langSegment; }); wire()->addHookAfter("InputfieldPageName::render", function($e) use($hookId){ $e->removeHook($hookId); }); });

Thank you for your quick reply and fixes! I just sent you a paypal donation.

ProcessWire 3.0.180 contains 20 commits containing various minor new features, issue resolutions and pull requests. While there's no single major feature to write a big blog post around, combined there are a lot of worthwhile and useful updates so this version is definitely worth updating to. More details can be found in the dev branch commit log and at ProcessWire Weekly (issue #370 covered an addition to our $files API var). Yesterday the forums were running a little slow because we had our yearly DDOS’er pay the site a visit once again (remember last time?), and from an apparently unlimited supply of IP addresses around the world this time. We shut down the forums to users that weren't logged in while the load was high. Actually, it does this automatically now. We also updated the forums from using memcached to AWS Redis, which should also help as a nice upgrade for the forums. Big thanks to @Pete and @Jan V. for setting it up and keeping everything running smoothly. I'll keep it short today because it's supposed to rain here all weekend, so I'm going to spend some time outside while I can. Thanks for reading and have a great weekend!

Hi everyone. It's been a while. A little update. There has been a delay, again, unfortunately! Lockdown hit really hard. There were also a number of technical issues but these have since been resolved. Finally, a number of you (having seen the preview videos) strongly expressed the need for the Padloper UI to resemble the ProcessWire admin theme even in the alpha stage. The message I got was that this was more important to them from the get-go than having advanced Padloper features. I accepted their reasoning but this came at a cost. Padloper 2 has been re-themed to look like the ProcessWire admin. Given that we are using third-party libraries to build Padloper 2, this took a lot of time. Focus was placed on basic features only, for now, in order to expedite the first release of Padloper 2. This means that some advanced features will be missing from the first release of Padloper 2. As for a release date, I was hoping for a 'spring baby'. That won't happen. I am now working hard toward a 'summer baby'. Screenshots Have a nice and safe day.

Same as @diogo already said... I don't know and don't understand almost anything you wrote @hellomoto but eitherway... I know how it feels to be lost in some kind. Never had to deal with things you wrote in your first post (I read it, but won't cite it as you deleted it). All I can say, which is almost what Diogo already said... I won't make fun of you. Never. You are part of this community which is more important that anything else. Yet... I'll offer you an "open ear" for conversation, talks, exchange for all kinds of topics. I remember a time I needed something like that but haven't had anyone... so... the thing I can offer you is... someone to talk to. If needed and wanted. We all have some kind of daemon or daemons which follow us in some kind or another. Either in real life or in mind which disrupts our real life. No judgement or anything like that. Talk to me about the things that keep you in trouble. Drop me a PN for contact details. We can talk via whereby, Skype... whatever. Let me know. I won't let someone from this community go down a dark spiral. Talk to me. We are friends. Even though we don't know each other. Yours, Alex!

Note that when using id="date" you may only use one date on one page. I'm not using HannaCode at all, maybe you can use PHP to generate an unique id? <?php $id = "date_".uniqid(); ?> <p id="<?= $id ?>"></p> ... document.getElementById("<?= $id ?>").innerHTML = datum;

@ryan - I just tried working with this for the first time and the issue I am having is that I don't want to prevent guests from viewing the page, but I want to prevent them from being able to view the PDF associated with the page. Of course, the first level of protection is to simply not show them the link to the file, but if they were given (or guessed) the direct url to the file, I don't think I can actually use pagefileSecure and this new approach to block access, or am I missing something? Perhaps pagefileSecure needs to have an optional permission, eg 'files-view' or something like that - I think that would allow much more flexibility in controlling access to files without relying on access to the page they are stored on. Does that make sense?

Glad you found a solution by placing under admin, but if you want, here is a tested option. Place this in your admin.php - just replace the xxxx with the id of the Settings page. With this the autocomplete won't return any pages under Settings. $this->pages->addHookAfter('ProcessPageSearch::executeFor', null, 'removeBranchFromSearch'); function removeBranchFromSearch($event) { $response = $event->return; $responseArray = json_decode($response, true); $matches = $responseArray['matches']; $i=0; foreach($matches as $match) { if(wire('pages')->get($match['id'])->is("has_parent=xxxx")) { unset($matches[$i]); } $i++; } $responseArray['matches'] = $matches; $event->return = json_encode($responseArray); }

@mr-fan, This actually should be quite simple. Add an after hook on: ProcessPageSearch::executeFor and call this method: public function removeHiddenFromSearch($event) { $response = $event->return; $responseArray = json_decode($response, true); $matches = $responseArray['matches']; $i=0; foreach($matches as $match) { if($this->pages->get($match['id'])->isHidden()) { unset($matches[$i]); } $i++; } $responseArray['matches'] = $matches; $event->return = json_encode($responseArray); } This will remove all hidden pages from the results, but I get the feeling the pages themselves are not actually hidden, just the "Settings" parent. Is that correct? In that case change "isHidden()" to check if the page is a child of the "Settings" parent - I'll let you figure that out

Under your template's Advanced tab, you can add your field names under "List of fields to display in the admin Page List" Update: There also this (not sure on 2.5 compatibility, if that's what you're using)

There's no reference, it's a normal page. The only reference is the pagetable field itself. Ring a bell? $thepage = $pages->get("template=basic-page, mypagetable=$page");

It's pretty easy if you are doing a before hook because the page's 'id' will be 0. But I'm guessing you need an after hook. ProcessWire doesn't populate the page's 'created' date until after it's been loaded from the database the first time. As a result, your after save hook can check the $page->created property. If it's empty, then the page is new.