Leaderboard

This works: $this->addHookAfter('Pages::cloned', function(HookEvent $event) { $p = $event->arguments(1); $p->created = time(); $p->save(array('quiet' => true)); }); This doesn't handle "modified", but for my needs I don't need that because publishing the newly cloned page will adjust that automatically then. But, if you do, you could add this to the hook: $sql = "UPDATE `pages` SET `modified` = NOW() WHERE `id` = '".$p->id."';"; $this->wire('db')->query($sql);

Update version 006 - 11 May 2019 Finally got a bit of time to work on this module. Changelog Namespacing: ProcessWire 3.x Support only from now on. Removed the module's CSS and JS files. They are unnecessary. Switched to $files->render() instead of wireRenderFile(). Option to check for and optionally use InputfieldAceExtended for code highlighting in the PHP custom code textarea. Thanks to @adrian , @diogo and others who suggested this. Option to specify number of rows for the PHP custom code textarea (@note: for some reason, it's not working with Ace Extended. It does work with plain textarea). Removed the option (in field settings) to search for files to render under /site/modules/FieldTypeRuntimeMarkup/ as these could get overwritten during upgrades. Refactored code to prevent unnecessary re-rendering of output, thanks @adrian Render PHP file mode is now supported for frontend use as well, thanks @Noel Boss Changed license to MIT. Please note this is the new master and is available in the modules directory. Screenshots Over to you @bernhard ?.

Thanks for your thoughts @wbmnfktr - it's actually weird to me that the core module is called "Clone" but the page list action button is called "Copy". I kind of agree with clone having the same dates because a clone should be identical, but I also don't think that in reality anyone actually wants a clone in the end - usually it's just a quick way to start a new page from existing content and modifying it to your needs after that. An option for changing the behavior might be a decent approach to the problem. Anyone else have any thoughts? I think in reality I'll probably end up hooking into ___clone or ___cloned and adjust "created" via SQL (or the quite save option) because I don't honestly see that Ryan will want to change the current behavior.

Maybe the earlier members will remember this one from 2014: What results in very nice reactions like Today the newer IP-Board has something like this already included. The only thing, that I would change today, is to add the given reactions of the top posters to the overview screen. Until today I have not known that this gets displayed when you click onto ones reactions sum.

Hello, you need somthing like this?

You might want to ask @kongondo what the requirements are to join his project: https://processwireshop.pw/ There are similar threads too, like:

Good point, I probably should edit the first post to contain the download links... ? Currently they hide in the second post from April, 12th.

Btw, mainly for @bernhard and @adrian who have previously looked at RTM code, InputfieldRuntimeMarkup now behaves similar to many inputfields in that it gets its values from the Fieldtype's wakeupValue(), i.e. from $this->attr('value'). The previous implementation seemed a bit unclean to me when I looked at it recently. We had the inputfield doing its own eval() or wireRenderFile(). Now I've moved everything to FieldtypeRuntimeMarkup plus added a small helper class in there to handle such things. All the inputfield does now is serve values, as inputfields are meant to do.

And... please don't get me wrong here. I'm the last one who is against a cool and exciting fun project. I just don't think this will really work out that well.

Thx @horst I know that this is easy to fix, but I don't think that we should have to think about that! The API is there to make things easy and bulletproof. So the problem is that someone might develop a module on a unix system, thinks that everything works properly and then a windows user gets an error because the implementation of converting file paths to relative urls didn't think of that case... Thx for that hint Horst! I've created a new PR that merges to the DEV branch ? https://github.com/processwire/processwire/pull/143 Is your implementation better in any way than my 2 line version? https://github.com/processwire/processwire/pull/143/files (in other words: Did I not think of anything?)

The second install is probably working on a smaller site (less than 200 MBytes of data), so the re-opening mechanism is not triggered at all. I guess you edited the pathnames, since the /**/ looks weird to me and I'm missing the domain name. Does your domain name contains a dash? Then this fix should help:

afaik no, but you could use a repeater instead.

I've never needed to use ProcessPageClone but I would have expected the created/modified time to be set to the time the new page is cloned from the old page. Maybe there are use cases for cloning the created/modified times, so perhaps the issue could be a feature request for the option to determine what happens to created/modified times on the cloned page?

Hi @stuartsa, welcome to the PW forums. ? Publishing a new page that is created via the API is not an extra action because pages are published by default. Or more accurately, they are "not unpublished" by default, because being unpublished is an extra status that you may add to a page but is not present by default. When a page is created in the admin via ProcessPageAdd it gets the unpublished status added because the expectation is that the user probably wants to populate some fields in a following step before the page becomes accessible on the front-end, and also because new pages can be added by roles with more restricted permissions than superuser. But when you add pages via the API then you are an unrestricted superuser and so it is up to you to populate the page fields and set page statuses as you see fit. Yes.

In this week’s post we’ll shift focus a bit and take a look at the latest version of FormBuilder (v38) just released today. It ends up being a fairly major release with a lot of new additions, optimizations and updates— https://processwire.com/blog/posts/formbuilder-v38-released/

Wow super! The API system look amazing! I know you still have to tell us many things, like how works the discounts, users management, shipments, payments, etc. But I will like ask a few things ? The API system for get the $order data will change? eg: At the moment I am using the success page or the checkout page to send the order data to external platforms such as our management, Mailchimp, google analytic etc. Will it be possible to continue doing it from there? I see there is the discount page, but also will be possible to change the price in the shopping cart based on the items loaded? eg: discounts based on quantity. Will it be possible to do this as a backend or do it with a separate hook? Will it be possible to choose the type of shipment in the checkout process? eg: normal, super fast... A curiosity, are you also creating new payment module? I think that ProcessWire has the potential to become the cms with the best e-commerce system around!

Just want to announce that I've uploaded a first public beta to the ProFields board. So all owners of ProFields may give this module a try:

Here you go amigo https://github.com/OrganizedFellow/LAMP I've had that readme.txt for a while now, making edits as needed and I suppose it is now ready to share with the community ?