opentype

Just to get all the possible views: I see no problem with it at all. It’s not the early days of the internet or the personal computer where sticking to ASCII was necessary or recommended to avoid technical problems. It’s the Unicode era now. If my user’s names are François, Käthe, Zoë, Carmiña, Åbjørn and so on, I am happy to have them use their correct spelling. The software can deal with it, search engines can deal with it. It’s really not a problem.

It would relate to the window size. If you set it to 50%, it gets too small on a phone, but get huuuuuge (and blurry again) when someone reads the email on a desktop computer on 30 inch screen.

If it’s a high-resolution screen the original size will indeed look a little blurred. To solve it, showing the logo in like 50% would be better and make no difference for people who have a regular resolution. That’s what I do for the theme logo as well. I wouldn’t use a percentage, no. It should be an absolute pixel value.

Personally, I wouldn’t bother with it and just use the original image size. If you really need to change it, you would have to customize the email wrapper template under Customization → Appearance → Email → Email Wrapper. It’s this line that automatically uses the image size: <img src='{file="\IPS\Settings::i()->email_logo" extension="core_Theme"}' alt="{setting="board_name"}" width='{$imgDims[0]}' height='{$imgDims[1]}' /> You could use hard-coded values for width and height, for example at half the size of the image.

It’s fully automatic, as these blocks are just feed blocks. They just take the data that is there. The forum images are taken from the attachments uploaded to the posts or topics, so they will usually be useful representation. If it shows outdated content, it might be a caching issue.

It’s unlikely to happen though because of all the dependencies (like member IDs, foreign database IDs et cetera) in those databases. They could be deleted between export and import, which would essentially break site.

No, Commerce doesn’t allow users to sell to each other. It only allows the site owner to sell products. And physical sales will removed in the future. User-to-user sales are not possible without third-party applications.

If your physical folder was “/forums/”, I think you are lucky, because that will also be the default forums folder once you make Pages the default app. So, everything in the forums should continue to work as always.

It depends on the type of quotation mark. Those " are removed. Proper typographic quotation marks like those “ ” are not removed. They are just treated like any other character.

What’s the problem exactly? I’m not seeing any problem with fluid mode.

You could create a feature request for IPS about showing the rating value with Pages database records. That’s more of a core function.

The alternative to “you are correct” is not necessarily “you are lying”. You can simply be mistaken and that is what is being pointed out to you.

[ { "line": 604, "function": "delete", "class": "IPS\\File\\_FileSystem" }, { "line": 167, "function": "getValue", "class": "IPS\\Helpers\\Form\\_Upload" }, { "line": 147, "function": "setValue", "class": "IPS\\Helpers\\Form\\_FormAbstract" }, { "line": 176, "function": "__construct", "class": "IPS\\Helpers\\Form\\_FormAbstract" }, { "line": 40, "function": "__construct", "class": "IPS\\Helpers\\Form\\_Upload" }, { "line": 1385, "function": "__construct", "class": "IPS\\Helpers\\Form\\hook1565" }, { "line": 107, "function": "editPhoto", "class": "IPS\\core\\modules\\front\\members\\_profile" }, { "line": 81, "function": "execute", "class": "IPS\\Dispatcher\\_Controller" }, { "line": 24, "function": "execute", "class": "IPS\\core\\modules\\front\\members\\_profile" }, { "line": 153, "function": "execute", "class": "IPS\\core\\modules\\front\\members\\avatarhub_hook_profileController" }, { "line": 13, "function": "run", "class": "IPS\\_Dispatcher" } ]

I can confirm the problem.

I would expect the code to still be correct. You might have made a mistake while setting it up. If not, I would start by outputting all the variables from the wrapper block to see if they are populated as expected.

Here is one from last year with a mention of a fix in 4.7.

I remember discussions about this years ago. I don’t know if it was ever addressed.

When I say you can’t do it, then I am referring to native functionalities. With custom coding, almost anything is possible.

Pay attention to this line in the categoryHeader template of the Listing template group. {template="categoryRow" group="category_index" location="database" app="cms" params="$cat"} The group name, here “category_index” points to the template set that is being used. This can be different from the category template you have chosen for the database. You might need to change that name so it matched the category templates you have customized. In general, your process is correct. It just looks like you are pointing to two different categoryRow versions.

This is mixing two topics: crawling and indexing. It’s better to address them individually or it gets messy and confusing. “crawled, currently not index” is entirely Google’s decision. It does not depend on any settings and there is nothing you can do about these individual URLs. It’s Google’s judgement of the actual content and its relevance for Google’s users. Crawling everything in the sitemap should be fully automatic. You don’t need to submit anything manually. Technically, you don’t even need a sitemap. It just helps the process and avoids unnecessary crawler traffic. You didn’t say whether your forum topics are actually crawled successfully. If not, there could be technical problems. If they are crawled but not indexed, then everything you need to know will be in this list in the Search Console: We could only speculate. The useful facts will be in that list.

Sorry, it’s not clear what you are asking. What change have you made to which template specifically? And where do you expect it to appear? By the way: Never touch the original templates! Always create custom templates first before making changes. Making changes to the default templates is irreversible and will cause unnecessary problems in the future.

The use of the Pages database relationship field creates a comma-separated list for outgoing and incoming links. This is usually fine when there are just a couple of entries. But there can also be hundreds of entries and then the field becomes way too limited. Suggestion: Ordering becomes an issue. With 100+ entries, there needs to be admin-defined ordering based on fields (e.g. title or custom fields) or something like record ID, publishing date et cetera. Just like it exists for the database itself. In fact, taking over the ordering from the specific database being linked would probably solve it for most cases. Pagination becomes necessary when there are lots of entries. Template. Make the field output part of the Pages template system, so it can be customized on a database level. (So far, we had to hack the theme templates, but that won’t be easily possible anymore in 5.x).

It has often been pointed out that adding links to external Pages databases is problematic, when the external record doesn’t exist yet. That would need a way to add these external records while creating the record from the current database. This feature request is related but about the other direction. I run into this problem all the time with linked databases. Let’s say I have a book database and a separate “book list” database, where users can create lists of books using the database relationship field pointing to the book database. It would be expected, but it’s currently not possible to add a book to a book list while you are browsing the books. Instead I have to open the book list database in a separate window, find the right list, and then find the book again, which I had already opened. Not very convenient. It would be nice to be able to set the incoming links right from the record view. In the template section, where the loop for reciprocal links appears, add buttons “add this [local db word like ‘book’] to [external db word like ‘a booklist’]”, which opens a pop-up to search for existing records in the external Pages db or offer an option to create a new one. This would be useful for almost all use-cases of linked Pages databases.

You can’t. You could however create “landing pages“ for each topic, where you add feed blocks from the separate areas. So you could have “lastest marriage articles”, “latest marriage forum topics” and things like that together. And from there people could click through to get to Pages or the Forums.

Nope.