Leaderboard

Hey @cjx2240 I recognized that this behaviour only occurs when I inspect the website with the dev tools and the "user agent" is changed. To prevent this I added the following entry in the site/config.php file: /** * Prevent from being frequently logged out while using Chrome DevTools * */ $config->sessionFingerprint = 2; Hope this helps you too. To make it save for production you could check if $config->debug is true and wrap this with an if query-.

My first thought is to use Redis for your session storage. I have a modified SessionRedis module that works on PW3.x with Predis if you want a copy.

Hi all, I've just put online on my server a new website, and I'm faced with an issue that so far I'm unable to solve. I've edited both the wire/config.php and the site/config.php to $config->debug = true; but when I go into Modules to add a new one, I always get this message: This issue doesn't appear in my local version, while it shown in my server version. I'm currrently unable to figure out any way to overcome this issue (ProcessWire 3.0.174). Can anyone help me solve this issue?

Here is the first very early concept of a Page Builder. As per the conversation in the 'ProcessWire beyond 2021' conversation, I set myself a challenge to make a clone of YOOtheme Pro's Page Builder. This was mainly spurred by @Jonathan Lahijani's excellent overview of ideas of a page builder for ProcessWire. This is still in very early stages and I am not really sure where it is headed. I would like to hear the thoughts of like-minded persons ?. I would especially love to hear from @Jonathan Lahijani, @szabesz, @AndZyk and @flydev ?? please. Concept The page builder in its current state is a Fieldtype + Inputfield supported by other behind-the-scenes Fieldtypes without Inputfields. There are no hidden or extra pages in contrast to Repeater Matrix. All values are stored in the Page Builder fields for the page being edited. The fields do not store values as JSON. Definitions for elements, rows, grids, etc as stored as JSON. Currently, for storage purposes, 4 datatypes are supported - Text (HTML), images, plain text and headlines. From a storage perspective, the latter two are one and the same. Just texts with different 'schemas/definitions'. More on this below. The fields are multitype fields. This means one page can hold multiple texts, allowing for repeatability. Similar datatypes are stored together in one field/table. For instance, there is no reason why a (future) URL element (datatype) should not be stored in the same table as plain text. At the database level, they are both just texts with similar requirements. At the processing level, URLs vs other plain texts (headlines, etc) are handled differently (validation, sanitisation, etc). Each 'element' represents a row in a table for most types (e.g. slideshows are slightly different). Querying and access of field values is via the main Fieldtype - FieldtypePageBuilder. However, the supporting Fieldtypes can be also be accessed and queried individually, if one wishes, using normal ProcessWire selectors. The supporting Fieldtypes, if such need arises could easily become custom tables instead (but best to keep them as Fieldtypes - easier querying with selectors, etc). It is totally CSS-agnostic in relation to frontend output. You bring your own CSS. In the preview, you can also use your own CSS. In the frontend, you can choose to output raw values as you wish or use inbuilt render methods to render the whole layout for you or to render the value of an element as per its tag definition (e.g. headlines as h2, h4, etc) where applicable. Fully multilingual (although the editing UI not yet implemented). Issues The main issue is the real estate needed for InputfieldPageBuilder. Any such page builder would require the whole width of the window. As you can see from the screenshot below, this obviously throws things out of kilter with respect to the ProcessWire page edit UI, in any theme (I believe). I am not a designer so would love to hear from you about possible solutions. My current thoughts are: Modal Open the page builder in a modal for editing. Pros Would allow for use of whole real estate. Title and other fields would not be in the way. Cons Editing in modals can be tricky? Other..? Process Module Pros Solves the real estate issue. Cons Disconnect between the page being edited/created and the page tree. Screenshot No attempt has been made to theme it as per any current ProcessWire theme (that I know of). This was a quick and dirty-ish clone of YTPB. As stated, however, the current ui is not acceptable as an Inputfield for, mainly, real estate reasons. Video Demo This is a demo for the Page Builder app outside ProcessWire. Thoughts? Thanks. PS: I currently have no time to continue working on this (Padloper, etc..)

It took a little more time this week to wrap up what I was finishing last week (and the week[s] before). But I think it's now at a good spot to move on to something else, and so I started with some Repeater and RepeaterMatrix updates. In Repeater, a new feature was added that's been requested for awhile: the ability to add items anywhere you choose. Previously you could do it only by adding items to the bottom, and then drag them in place. Now you can click insert before/after [icons] in each repeater item header and it will add the new item in place. It is also depth-aware. This is something that I think will also be useful especially for people using repeaters for page builder type contexts. (Note: the feature does not [yet] work if you have all Ajax features turned OFF in your repeater settings). There's a GIF screencast below that shows you how it works. You can click the "insert before" or "insert after" actions and it inserts a new item in place. Alternatively, if you hover either action for a second, it'll show you where it's going to insert an item and you can click either the the item, or the action, to complete the insertion. There's still likely some optimizations and improvements to make in the JS here but so far it seems to be working well. (I made this as a GIF but for some reason IP.Board won't accept it, so here's a YouTube embed instead): Everything in Repeater also gets inherited by RepeaterMatrix, so you'll find this feature there too. But it's not fully functional there just yet. That's because RepeaterMatrix items also have a "type", so I'm working on a new version of RepeaterMatrix that lets you select a type once you've chosen where to insert the item. Another related feature in progress in RepeaterMatrix at the same time is a dropdown/select option for choosing what matrix type you want to add for items. This is an alternative to the current list of links that appears at the bottom. The dropdown also gives you the option of having groups of related types. More on that soon, potentially next week. Thanks for reading and have a great weekend.

Usually we sanitize at the earliest opportunity available. It is also good practice in case you forget or move things around. So, this is better and less verbose: <?php $url_exhibition = $sanitizer->name($input->get->text('exhibition')); ?> As for which sanitizer method to use, the docs are helpful, but you are probably aware of it already. Just nitpicking now... You could probably check if $url_exhibition is NOT empty before continuing with the subsequent code, i.e. the pages->get and the rest of the code ?.

Also the use of the 404 Logger of JumpLinks module can fill up a DB drastically. There is a button available to clear that list manually.

Glad you got it sorted. I have just noticed that you are using a GET input in a selector without sanitizing it first. Here: $url_exhibition is not sanitized and you immediately use it here:

I've been using Bootstrap since 3.x compiling my own customised version from less with 3.x and then SCSS with 4.x I'm yet to jump to 5.x I've taken a look at Tailwind a couple of times, and the good thing is it seems to produce very small CSS, but the process of getting set up to compile a minimised version seems to be more complex and requires more tools than with Bootstrap. That's a one off I guess, and once you're set up then presumably it's straightforward. I do like Bootstrap's components. I'm a developer, not a designer, and when a client asks me "What can you make my website look like?" it's really handy to be able to say, "Here are a set of components you can pick from. I can change the colour, size and position any way you like." That's way easier than trying to explain the intricacies of CSS and that technically, I could probably make their website look like just about anything from dog's vomit to the crown jewels.

It's very likely, as this post in the module's support thread suggest: I'm not familiar enough with ProcessChangelog (nor ProcessDatabaseBackup) to guess at the technical issue behind that, but maybe @teppo as the module's author can shed some light on it.

More likely memory_limit, not post_max_size. The first thing I'd try is to uncache pages in your executeAction method, but if your database is huge (any kind of logging going on like ProcessChangelog?) upping memory_limit might be the way to go.

Hi @gregory. Session or cookies.

Hey @Clément Lambelet ! Thank you for using AppApi and for mentioning the questions! I do not know a way to prevent ProcessWire to log the accesses starting with /404/. From a technical point of view, this is absolutely correct: to accept requests, the AppApi module hooks into ProcessWire's 404 handling. For example, you call the url /api/test, which does not exist in the ProcessWire page tree. So ProcessWire handles this as a 404 error, but the module intervenes and sends its own output, namely what is defined in your routes. However, when logging, the URL is still recognized as a 404. In the newer ProcessWire versions there is the possibility to handle requests programmatically without the detour via 404 pages, but because of the backward compatibility I haven't dared to do it yet. If someone already knows better about it: I would be very happy about pull requests or comments ? No, that is absolutely legitimate and not paranoid! My goal is to make the module as secure as possible, which means that login via api must not open a way to undermine any security mechanisms. Speaking of Session LoginThrottle: I tested it out - LoginThrottle seems to be called correctly on the AppApi login calls as well. For example, if I enter an incorrect password three times in quick succession, I get the following feedback, which comes from LoginThrottle: { "error": "Login not attempted due to overflow. Bitte warten Sie vor dem n\u00e4chsten Login-Versuch mindestens 5 Sekunden." } Do you have anything special set that is not being taken into account?

I've just encountered the same issue. Tried to install a module on a site I had finished about 5 months ago. Tried adding the various config settings, etc. k07n's suggestion to check the php zip rang a bell. Only then did I see that I was on php 5.x (which I updated to 7.3) and had zip disabled. That did the trick!

I was fighting same issue once. Four hours to understand that I forget to install php-zip ^_^.

These should also work (on dev): // save directly from page object $page->save(array('quiet' => true)); // save just 1 field from page object $page->save('myfield', array('quiet' => true)); When quiet mode is set, the modified date is set to whatever is specified in the page. Meaning, the modified date is not updated unless you change it yourself. Quiet mode also lets you modify the modifedUser and createdUser for the page, if you want to. These are two properties you can't usually modify, but quiet mode lets you do it.