LostKobrakai

Does this image removal only happen for the image in the ckeditor or do images also disappear from the image field of this page? Do you have image-management (content type) enabled for the textarea?

The "Compatibility Check" does only check for the availability of the needed php modules. It does not check your mysql connection settings/credentials, as these are not provided at this step of the installation. The error messages you posted should be descriptive enough. The first one tells you, that you're credentials didn't work and the second error tells you that a potential connection via sockets (e.g. /some/path/mysql.sock) didn't work, because the file at the path that was provided didn't exist. ProcessWire cannot give you more information as it would be pure guesswork why the connection was rejected.

That something that shouldn't be done before drafting will find it's way into the core. In my opinion content should never be overwritten automatically.

From a quick glance into the plugin it seems like antispam bee is build around wordpress, so it may be a bunch of work to separate the functionality from the wordpress specifics.

You should take a look at this: https://processwire.com/talk/topic/3579-tutorial-approaches-to-categorising-site-content/

OR operators do work in 2.6, but I'm not sure about the compatibility with repeaters.

The images with captions are wrapped in a <figure> tag to appropriately markup the caption as <figcaption>. This html tag is a block element, so you'd need some css (float or display: inline-block) to make them flow next to each other.

Oh sure, the hook runs after the trashing, so the page does already have the trash as parent at the point when the method runs.

But maybe this could be an alternative: http://processwire.com/blog/posts/language-access-control-and-more-special-permissions/

public function trashDuplicates($event) { $page = $event->arguments[0]; if($page->parent_id == 1023){ foreach($page->translated_pages as $translation){ $this->pages->trash($translation); } } } public function deleteDuplicates($event) { $page = $event->arguments[0]; // It may be trashed, where the parent is not 1023 if($page->is("template=article_english")){ foreach($page->translated_pages as $translation){ $this->pages->delete($translation, true); } } } This code shouldn't error like your error message, as pages is no longer the variable.

Yeah, use $this->pages...

It's the right one. You want to delete the translations when the english article is deleted, which in this case it $page. It's in all three of your methods the same that you're initializing additional changes if the english article happens to change/be added. But sadly I can't see why it's not working. It not like it's much code which could have errors.

I'll doubt this will find it's way into the core as extension of FieldtypeImage. A images field is a field to store images, not to choose them. Fields are first and foremost there to hold data. If you want to choose images then you'd need some kind of reference field, that just stores references to images, then it doesn't matter if they are from the current page or from another one.

<?php class DuplicateArticles extends WireData implements Module { public static function getModuleInfo() { return array( 'title' => 'Duplicate Articles When Created In English To All Translations', 'version' => 1, 'summary' => 'Module to create duplicate of English (master) articles as pages in every translated language.', 'singular' => true, 'autoload' => true, ); } public function init() { $this->pages->addHookAfter('added', $this, 'duplicate'); // This hook occurs right after saving the trash status $this->pages->addHook('trashed', $this, 'trashDuplicates'); // This hook occurs right before final deletion $this->pages->addHook('deleteReady', $this, 'deleteDuplicates'); } public function duplicate($event) { $page = $event->arguments[0]; // Only duplicate pages under /articles/ if ($page->parent_id == 1023) { $translations = new PageArray(); $a = new Page(); $a->template = 'article_french'; $a->parent = wire('pages')->get('/fr/articles/'); $a->name = $page->name; $a->title = "{$page->title} (awaiting translation)"; $a->status = Page::statusUnpublished; $a->save(); $translations->add($a); $b = new Page(); $b->template = 'article_spanish'; $b->parent = wire('pages')->get('/es/articles/'); $b->name = $page->name; $b->title = "{$page->title} (awaiting translation)"; $b->status = Page::statusUnpublished; $b->save(); $translations->add($b); … $page->translationPages->import($translations); $page->save("translationPages"); } } public function trashDuplicates($event) { $page = $event->arguments[0]; if($page->parent_id == 1023){ foreach($page->translationPages as $translation){ $pages->trash($translation); } } } public function deleteDuplicates($event) { $page = $event->arguments[0]; // It may be trashed, where the parent is not 1023 if($page->is("template=article")){ foreach($page->translationPages as $translation){ $pages->delete($translation, true); } } } } Not tested. Maybe it works out of the box, but at least it'll get you started.

$a = new Page(); $a->template = 'article_french'; $a->parent = wire('pages')->get('/fr/articles/'); $a->name = $page->name; $a->title = "{$page->title} (awaiting translation)"; $a->status = Page::statusUnpublished; $a->save(); $b = wire('pages')->clone($a, wire('pages')->get('/es/articles/')); $b->template = 'article_spanish'; $b->save(); $c = wire('pages')->clone(…); … Depending on how you need it. Hooking Pages::delete runs only if a page (the english one) is deleted. So if there's no english version then potential translations won't be removed. If you want to check for orphans in the translations more often you could also hook Pages::saveReady, which runs every time a page is ready to be saved to the database.

Try $pages->clone($page[, $parent]) and just change what needs to be changed. Add a pagefield to the template of your articles, where you store all the translation pages (if you don't already have that). Hook Pages::delete and if it's an english article delete all the others, too. You can even hide this field from the backend, so admins cannot tamper with it. I'm not sure if I understand correctly what you want to archive, but setting the id of page $a seems to be wrong. // Add the english page to the field "related_page_language" on page $a. // Single page $a->related_page_language = $page; // Multiple pages $a->related_page_language->add($page->id);

The better way of excluding the admin is this: $matches = $pages->find("has_parent!=2"); This excludes every child of "Admin", which has a hardcoded id of 2. That's more flexible than just excluding admin as for example users ("template=user") are also part of the admin.

Don't take this as personal offence, but that's not a fair statement to make about ProcessWire. The problems you had with updating your backend are inherit to using relational databases and not specific to the cms. You could've used any of the nosql databases out there, but that's a whole other story and quite different in terms of content management. Stating that the system was never designed for registrations, a great user base or for mobile api's is a plain wrong accusation. The system was not designed for plug-and-play, that's true, but it gives you the full freedom of implementing registrations and api endpoints just like you need them. At the core ProcessWire is more like a cmf, so what you do with it is up to yourself.

That the template is still visible in the dropdown is not how it should work. The second part is different. In the backend there could be a "second" check after submission of the page-add form and before the page will be finally saved, but really hiding it from the dropdown should be enough (as long as it works). From the pure api side there's no restriction to prevent the addition of new pages.

That's how you would set the a options field if you want to define it by a value – myValue in this example. Otherwise you have to use the id.

@Soma Directly setting the value doesn't work, even though I would like it to do so. $field = $fields->get("optionField"); $options = $field->type->getOptions($field); $page->optionField = $options->get("value=myValue")->id;

https://processwire.com/talk/topic/9832-how-to-create-an-action-in-an-admin-page/?p=94500 Something like this. Create the page in the " addButtonsMethods" via the api and then redirect to it.

Just create the page via the api and then link to the edit page of this new page.

This only works as long as a page isn't live. As soon as it's published all changes to it will be published, too. A page does currently always have a single state in the database to which you save your changes. There's no second set of "draft" values.

There's currently no drafting feature in ProcessWire. A page is therefore either live or not and there's always only a single version of a page to save to.