LostKobrakai

@diogo I was about to write the same thing earlier today, but it's not right. It would be right it were PageArray::find, but $pages->get("/fonts/") returns a Page and not an array of pages. Page::find() does essentially what you suggested. It rewrites the selector to include "has_parent". So no need to do this manually in this case. @rooofl It's strange that it would work without the find() method as you cannot paginate the result of $pages->get("/fonts/"), because it only returns a single page.

Maybe just look in the Suppor Forum of the module: https://processwire.com/talk/topic/201-fieldtype-select-aka-drop-down/?p=45320

Maybe this can be from interest, too: https://processwire.com/talk/topic/9305-the-pw-data-model-and-the-entitycomponent-pattern/

As seen from my post count I'm around the forums for quite some time already, which helps with sorting out issues. Also everyone here was at the point of having no clue about how the whole cms works. So I eventually had the same problem when I started using the form api.

Do you mean the summary field is not displaying text on the frontend or in the backend? If the latter, is it only collapsed or doesn't it even show text?

This really depends on your usecase. If both places should stay in sync than it may be a bit of work. If you only want to import changes in the xml file and the imported pages are not changed in the admin backend, than it's quite an easy job.

I don't know what the issue could be, but wouldn't it be better to store only the id or the url of the gallery instead of the whole page object?

Process modules are the type of module, that integrates as ui into the admin backend, so if you can make it do what you want than it's perfectly fine. Sometimes people do split up the processing in a separate module so it's easier usable from the ui (process module) as well as from the api, but it's not necessary to do that and maybe overkill depending on the needed featureset.

I don't want to nitpick to much, but there isn't even a new fieldtype necessary, as it won't even know the difference. Only the inputfield would need some enhancement to make this work.

You left out the part how you actually want to handle the data now. If you want them to get simple pages in processwire, than yeah, you'd build the templates to hold your data and then import the data as pages. For the importing part take a look at some of these: http://modules.processwire.com/categories/import-export/ If you need some more basic things for starting out, here you can find how you'd generate a page from the api: https://processwire.com/talk/topic/352-creating-pages-via-api/

Just had another look at it. This does only work with different domains, not with folders. ProcessWire does not check for folders here. But you could certainly just use an complete new installation in the subfolder. Edit: To make this clearer: ProcessWire does only compare the keys of the multisite array to the domainname. http://mydomain.de/folder/ Only the bold part is compared.

You're right, the domains need to point to the place where processwire is installed, so I think it's because of the folder setup. To make this work we'd need to have a little more information about how your domains and folders are set up.

I'll doubt that, because there's no inherently wrong userAuthSalt value. You hashed password just doesn't match the database value, but the system doesn't know why it's this way.

Not as unusual of an need: https://processwire.com/talk/topic/9879-fieldtypereference/ Edit: If you need the whole page instead of a field you'd just need to adjust the module by removing the whole "get a field" part.

No problem. With just imports/exports there shouldn't normally break anything. I do that all the time.

The mysql version should be fine. What exactly do you do when merging databases? I can imagine this creating a lot of havoc if not done with lots of care.

If I understand that right (never used any of those cms's / frameworks) than you should look at WireArray and WireData. These are the basic building blocks of ProcessWire and are basically the single and multi-entity data blocks. All other Datatypes build on this e.g.: User > Pagetype > Page > WireData PageArray > WireArray …. But I don't know of any specific "one to one" or "has many" relation, while "one to many" is just done by hierarchy (FieldtypeWrapper (Field) -> children (FieldsArray)).

You're right that "disable multilingual description" should to that. But currently it seems, that this setting is only blocking the rendering of the fields in the backend. Edit: Misread the file and just tested on a fresh 2.6 installation. It works, but only if it was never saved with multilingual descriptions enabled. Until it was saved once it will stay kinda multilingual. Added a github issue: https://github.com/ryancramerdesign/ProcessWire/issues/1161

Please do look in the forum before posting. This is a very recent topic, which should possibly point you in the right direction: https://processwire.com/talk/topic/9828-image-description-alt-tag-text-only-appearing-when-logged-in/?p=94620

I think the error is actually two lines earlier $this->addHookBefore($class.'::render', $this, function($event) { … }

Another small, but potentially helpful module. This fieldtype references a field in a page, where the field's data is retrieved from a somehow related remote page. It's kinda like a one way symlink to a remote field. To make this description a little easier to understand I'll just add a example. Imagine you've some pages placed all over the page-tree, but you need editors to be aware of a specific setting in a single page. With this Fieldtype you would set this up like this: - Get the page (php snippet kinda like for page fields) return $pages->get("/special-settings-page/"); - Setup template to field pairing settings=my_special_field - Add this field to any template you need this on. Now this special setting is visible in the backend, if someone edits a page with this reference field, and via the api as read-only field. The field can use all collapsed modes, which do not allow editing, so it can be hidden if it's only needed by the api. This can be useful for content heavy sites, where information is scattered around multiple (parent) pages, but maybe all information needs to be available for the children. It's also nice for creating (shorter) selectors for inputfield dependencies or dynamic page fields. More elaborate examples about this options can be found in the readme of the module. Todo Add checks to prevent infinite loops Maybe make it a field, which can be edited and saved. GitHub: https://github.com/LostKobrakai/FieldtypeReference

Pushed a small update, which removes path-details when access rights are not available, as it would falsely suggest that only under this path a role would have no access. Also added a bit of a description about how templates are distributed over the tabs. Also made the module officially 2.6 compatible.

Pushed a small bugfix and added 2.6 compatibility.

How about this? http://docs.ckeditor.com/#!/guide/dev_howtos_dialog_windows