ragnarokkr

@gebeer I moved away from WordPress years ago and the very first (and only) choice for this project back then was PW. I used and loved it at very first time and it really doesn't give me any pain its way to handle images. But now the customer wanna update and expand everything, and since his requirements for media managing are quite mandatory and an upgrade is required I'm watching for a solution which fits requirements and low-budget needs. I would never came back to WP if PW had this kind of field out-of-the-box. @Macrura Pages (system, locked, hidden, abstract or in parallel dimension) are still pages, with their path on the system which isn't decoupled by the CMS managing (nothing I can decide before and keep in future if deep changes are made). It's still a relative path to a CMS hierarchy of folders always affectable by changes made by the superuser. If I decide in future to implement any kind of system to furtherly decouple the media archive from the CMS itself (for example, by implementing symbolic linking via virtual FS on another server) or implement other kind of things to preserve integrity of media archive (like, just for example, some kind of remote backup process) everything will always relay on a path which could change through the time by external conditions, breaking the decoupling idea of set-and-forget settings and, more seriously, breaking all image links (imagine to fix 1 or more image links per page per thousands pages). @gmclelland Yes you got the point. A powerful CMS like ProcessWire that points to challenge the big ones on the market (and it can easily do that) should think about a solution out-of-the-box for media managing similiar to the one offered by the competitors. I'm not saying it has to provide n-thousands functionalities probably usefull for the 0.1% of the users, but a basic media library with the moreover already provided functionalities should be a must. (The CMS often is used for blogs and websites where presence of images is almost a constant, so the case is more than just a edge case IMHO.) For everything else there are hooks and plenty of space for developers to implement gazillions of features not basically required. I've no knowledge in PW core and no time to spend in research how to take this and that from here and there just to put together something working for my case in front of the low-budget situation, so I have to relay on the cheaper solution with the most complete offer, and actually WP is sadly the answer for this case. I don't like the choice but there's no a valid alternative solution. (I also took in account Ghost and Strapi - which is the most similiar to PW for Node.js, but both lacks of media management too.) That's it. If I will have spare time to go deep into PW core and find furthermore info about extending core Image module in order to add these functionalities, I'll do it with pleasure.

Yes I could hide the page but I need a solution that keep detached the source path from the CMS page management logic. Anyway as I said this is a low budget project, and I really have no time to spend in "artistic" solutions just to reinvent the wheel. I just moved back to WordPress ? and that's it. Honestly, I like the idea of the images following their own page because it guarantees a good degree of integrity with image links and the related page, but I also think it introduces a level of redundancy which can become really detrimental at an high level of managing (I'm thinking about - not so edge - cases where thousands pages have to handle more than 1 image common to each one) and I really think that an out-of-the-box system to handle this case via Image field should be mandatory for a CMS like PW. Nothing very complex, just some sort of merge of Image field's and ImageReference's logics to offer the power of the Image options (sizing, cropping, min/max sizes, etc) with the options of different sources. The rest should just be hooks, the developers could register to extend the functionalities. Anyway, thanks to everyone for your time.

@BitPoet One of my needs is to have a persistent system path, regardless the page tree structure, so the page as media folder isn't a viable solution. ? @gmclelland Thanks. It still relay on pages to work, which is something not usefull in my case ? @gebeer As said, I need a system folder as a source in order to have a persistent and common path regardless the changes an admin could do in future to the page tree, so the one page isn't a viable solution in my case. I know, I already commented the fix. You did a great work with that but as you said, mine is an edge case. Often the admin panel will be accessed on mobile devices and the narrow layout isn't something I can modify. As you can see, even with less than 10 images (and that's just a test, the production version expects thousands pages, with minimum one image per page) it becomes faster messy without a scrollable option. You can easily imagine how hard it will be on a mobile device. I know my case is very edge-case and I'm figuring out if there is a way to merge the already good out-of-the-box Image field functionalities with yours or similiar module, but my knowledge of PW core is very poor and is low budget work so I cannot spend too much time in reinventing the wheel.

Thanks @BitPoet. Yes I did already look at it. That's an interesting module but unfortunately isn't what I'm looking for because: I do need a separate field and not something bounded into the text editor; I do need a persistent image file path (not changing with the modification of the source) Until now what I did find that fits mostly to the needs it's the ImageReference module, but it still lack of the needs I have ?

Hi everyone. A lot time not writing here but periodically checking for the nice updates. I'm facing a problem and not able to figure out how to solve it easily ? (admitedly that something in programming is easy ?). I'm trying to implement featured and gallery fields for generic post. My problem is that I need to have the Inputfield reading/writing the images from/to a system folder rather than a page. Reason of that is that: customer stressed me out about the need to have a WordPress-ish ? central folder for images; if referencing images from a page, possible future changes to the source page will change accordingly all images src link, breaking everything (and I'm trying to keep the backend as lighter as possibile by not fill it with modules which keep track of this and that at every change). I'm actually using the great ImageReference module, but I'm still facing some issues I already exposed on its GitHub repo, which I'll try to summarize here: image preview not (yet) responsive in edit page, or at least in my case it doesn't work as (I) expected; no scrolling in image selection (widget expans a lot especially if the container is narrow); no description available for the uploaded images. What I would like to have is the power of the default FieldtypeImage combined to the huge range of choices ImageReference gives out of the box, but from what I did understand the author is not interested into merging the things. All this brings me to the final question, which is: since I actually cannot afford to spend a lot of time reinventing the wheel, and is low-budget work, is there a way to hook some event from the default FieldtypeImage right before it uploads or reads the file from the page's folder, in a way I can modify the path by routing it to a folder of my choice? I hope I've been able to make clear my thought ?

Hi @Robin S, I don't use Tracy Debugger so I can't give you any response about the issue you mentioned above but thanks for the link, just in case it will happens with some old PW version

I'm not using any VPN or anything else that could change my IP. The only thing I could think to is that something in SessionHandlerDB's tables/data has been corrupted for some reason and didn't allows me to login. Since I'm still not migrated to the lastest 3.x version, I'll take my time to do an as clean as possible migration, trying to remove every possible troubles maker thing.

No solution still, the only thing I've been able to do is to programmatically uninstall the SessionHandlerDB module. Now I've got again the access to the back-end.

Hi all guys! I've a BIG problem here and hope you can help me to solve it. Suddenly yesterday my PW installation stopped letting me to log in. I can access the front-end, but each time i try to log into the back-end it gives me "This request was aborted because it appears to be forged." I already have searched into the forum and tried every possible solution, without any result In order: site/config.php is readable site/assets/{cache,logs,sessions} is present and 0755 (and setting them to 0777 doesn't make any difference) tried to backup site/assets/sessions directory and make another new empty one nothing is changed with user:group permissions setting $protectCSRF, $sessionChallenge, and $sessionFingerprint to false the error disappears but the login page still remains making the sessions table empty doesn't make any difference enabled/disabled the www. redirection in .htaccess, just in case but nothing enabled $debug and no error removed cookies restarted the server Anybody has an idea?