-aj-
Members-
Posts
8 -
Joined
-
Last visited
Profile Information
-
Gender
Male
-
Location
Adelaide, South Australia
-aj-'s Achievements
Newbie (2/6)
14
Reputation
-
Released: PadLoper (commercial eCommerce platform for ProcessWire)
-aj- replied to apeisa's topic in Modules/Plugins
Hi Apeisa I'm excited about checking this out, I have a large number of sites that are stuck in WordPress due to eCommerce functionality being needed (EDD or WooCommerce handling it in those cases). I can understand the rationale for making 'everything a page' as it's doing things the processwire way, but I've found that it can cause issues by mixing user or auto generated content (orders etc) with content that may need to be more managed or version controlled. Many eCommerce sites are constant 'works in progress' or follow a continuous improvement cycle. Because of this it's necessary to run multiple versions of the site (at the very least 1 staging, 1 production: usually I run 1 local, 1 stage, 1 production). Trying to do so with EDD or Woocommerce is absolute hell because as soon as someone places a new order on the production site the others are out of sync, and I need to write specific migration code or do DB diff etc to be able to deploy changes. This is because in these systems orders are wordpress posts and order statuses are wordpress comments etc so if I've created a new post/page/anything in my local dev environment and someone has placed an order online, then it's almost guaranteed that we'll have a post ID conflict that we need to contend with. The devs of these plugins bascially just ignore it - most users are small and don't do any kind of test etc I'm just bringing it up so that you can see the implication of making EVERYTHING pages, most specifically customer orders. It would be excellent if orders could be separated out to a DB table so that changes can be made to local /staging copies with relative impunity without potentially clashing with user/auto generated content. Having a multi-stage development workflow is easy with any CMS if the data flow is unidirectional (with dev as the definitive source) , but things like eCommerce, Forums etc make the data-flow bidirectional (production and dev environments are authoritative sources for different information) and having them mixed up in the same DB table is just a huge mess. If I'm missing something here and this is already handled or accounted for then my bad, I just wanted to raise my concern so this doesn't suffer from the same pitfall that these popular plugins suffer from. Regardless I'm still very interested to see the progress of this platform. Thanks, Alex -
Login Issues on a new local install (already searched, checked guides etc)
-aj- replied to -aj-'s topic in General Support
Thanks for that post, my searches didn't unearth that. I know that session auto start is on, so I will have to see if I can turn this off just for this vhost via php.ini (I need it for some of my other local installs like WooCommerce). I'll give it a shot and see how I go, thanks for your persistence with helping me diagnose the issue. EDIT: resolved the login issue by setting session.auto_start to 0 for that vhost. Aside from my problems, is the issue with the admin usernames not throwing errors/validating something worth raising on github? -
Login Issues on a new local install (already searched, checked guides etc)
-aj- replied to -aj-'s topic in General Support
That's ok, I understand that you have no way of knowing 100% everything I've tried, or my setup, knowledge/skill level etc Tried 777, no change, I'm 100% certain that apache is running as my mac user (ie the user that also creates the folders etc), I'm really struggling to work out why this would be an issue for this PW install when all my local installs of WP are working perfectly and they require a very similar permission/user setup structure etc -
Login Issues on a new local install (already searched, checked guides etc)
-aj- replied to -aj-'s topic in General Support
I end up at the login screen with blank username and password fields. Sessions folder is 755, but there are no sessions in it, could this be the issue? from other posts on the forum I've read pw should throw an error or exception if sessions fail to write. Pre-login https://cloudup.com/ikThn76DC7j Click the login button and I get this https://cloudup.com/c74cMDvreF1 Thanks, Alex -
Login Issues on a new local install (already searched, checked guides etc)
-aj- replied to -aj-'s topic in General Support
As I've mentioned, I have searched through the forums looking for login and password related posts, and have tried some of the fixes mentioned. My password is not incorrect, but to be sure I too have tried programatically resetting it using snippets found on the forum, then trying the new password and the same behaviour happens.. every time.. I've tried turning on debug, but it's not immediately useful as no error is thrown when I use the correct username and password, I just do not proceed to the admin. I guess I could start hacking core to throw more info or errors out during the login process but I'd rather not.. it's literally a stock standard install running on MAMP, I've had PW installs on my local machine before. -
Hi All It's been a while since I've done any projects in PW and I wanted to check out some of the new hotness going on in dev branch, so I cloned the repo down etc Install went without any hitches, no warnings, all files/dirs appear to be created and writable etc. Problems begin when I go to log in to the admin section. After entering my username and password the page refreshes and just dumps me right back on the login page, with no errors, acknowledgements of success/failure etc I just keep getting hit with the same login screen. If I try a different (intentionally wrong) password it will throw a login failed error. If I try to many attempts too quickly I run into the login throttling, but when my details are correct it throws no errors yet doesn't let me into the admin at all. The front end of the default site works perfectly - no 500's, 404's etc I tried switching to the master branch, and doing another install from scratch, same problem. 1 thing I did notice when going through the install is that admin username is meant to be a-z 0-9 only (as per the field label), but it won't validate this or throw any errors when you use other characters (both client side and server side), my first install attempt had the username wire_admin, subsequent fresh installs have just used lowercase alphabet characters. My password currently includes symbols, caps etc, is there any restrictions on them in passwords? (and if so, why???) Any length limitations on usernames or passwords that could be causing issues? Searched for login errors on the forums, looked through the troubleshooting guides etc and none of them seem to mention my scenario (links / htaccess all working perfectly, just login issues, no errors thrown) Any help would be appreciated Thanks, Alex
-
Put your fallback image within a <noscript> tag, solves this issue (won't be inserted into the DOM /evaluated for SRC etc) unless JS is turned off, and keeps the fallback. Can bloat the code a little, but much less so than downloading 2 images. Also you could setup a build system like grunt or gulp to add the noscript fallback automatically during the build process.
-
I think that editing and content approval workflows are a great idea and I can 100% see the use case for them in enterprise application and large workflows. I don't think it should be part of core however. Keep core as lean and abstract as possible, not catering to any specific use case over another. These features would make an excellent module, or possibly multiple modules that work nicely together around each other such as page/node statuses, page/field version control, editing/approval workflows etc. Having them as officially supported/vetted paid modules would be the ideal scenario if you're trying to attract enterprise customers. WordPress gained a lot of larger publishers when it worked heavily on workflow / editing flow improvements (officially sponsored by Automattic as part of the WP.COM VIP program), but this was still done as a plugin because it's more than the average user needs, heck post versioning as it exists today in WP is likely WAY over the top for 99% of WP users and it just bloats the DB.