zyON

It seems like this hook doesn't work with other Lists, only on the Page Tree list (I'm using ListerPro). Any ideas how can I remove publish and hide buttons from lists? EDIT: Ok, forget it. The hook still works on a Lister. I had a debug message being fired on the hook handle function that was not appearing, but the unset of the buttons still work. ProcessPageListActions::getExtraActions

Robin, I don't have the "Unpublished" checkbox because I'm using the RestrictTabView module to hide the Settings and Delete tabs for this role. Thank you for the hooks code, this will come in handy very soon.

This is how I solved this question: I've assigned page-publish permission to the agent role so they can publish pages based on the property template. I've created a module that with a hook on ProcessPageEdit::buildForm like this $this->addHookAfter('ProcessPageEdit::buildForm', $this, 'removePublishButton'); The function that handles this just looks at the page being edited and if it has a status of Unpublished, it removes the Publish button: foreach($form->children() as $f){ if($f->name == "submit_publish" && $page->isUnpublished()) $form->children()->remove($f); // Removes the Publish Button from Properties not yet published. } This allows the users with agent role to edit already published pages (if they belong to them, something that the module also checks) but keeps them from publish new pages directly.

Hi. I'm going to bump this one alive again. What Adrian was mentioning is exactly what I need. I need to give some users (agents) the possibility to create pages with a specific template (property) but I don't want them to have access to publish it before someone checks if everything is correct. I've used the special permission page-publish and that takes care of that part. But I also need to give them permission to edit the page as soon as they are published so they can make alterations. I'm kind lost on how to handle this. I guess I'll have creat a module to handle this, but how can I override the page-publish behavior so it can give access to edit published pages? Or should I ignore this permission? Thanks in advance.

Wanze, yes thanks. I was missing the configuration options on the WirePDF module (was checking only the Pages2PDF module configuration).

Is there an easy way to remove the space occupied by the header? It's probably me or my setup but I can't seem to remove the space.

Sérgio, you're right. I thought you had to use S3 but you can use any server for CloudFront delivery.

Wanze: Thanks. You were right, I had to change it to DejaVuSans (but I also had to to copy the DejaVuSansCondensed family to the module ttfonts folder because it was looking for them somehow and throwing an error. I was using Helvetica and it should contain Portuguese characters... I'm using it on the site text too.

Yes, those are on the front-end, but all the other content is ok except for the text coming from the TextAreaLanguage :/.

Hi, I'm using multi language support and everything is working well (great module btw) except for the text coming from a TextAreaLanguage field where I get missing characters, like in Portuguese, that are replaced by '?'. Anyone having this problem or know what can be wrong? Thanks.

I've not tried yet to block other sites from hotlinking my CloudFront content. You can also check to apply a cache control http header on the module itself. It will apply it to every file uploaded via the module.

CloudFront uses S3. There's no other way.

Thanks. In the current version of the module it will only work with assets uploaded via the admin. That's something in the roadmap for me but I don't have a date I can share right now because I'm really lacking the time at this moment.

Manol, the plugin doesn't handle the deletion of the files in the assets folder. If the plugin is active, the files will be delivered through S3 without relying on the local ones , so theoretically you could manually delete them from you local assets folder but I think of it as a backup that you can quickly start using just by deactivating the plugin. EDIT: Sorry, I forgot to mention (too much work) that in the admin, the local files are used. So it's definitely not a good Idea.!

I'm not having that problem, but of course that depends on several things. If you can put the files on the webroot of your hosting root, I think you'll have no problems and can safely ignore the $config->urls->root "hack".