On this screen : https://equalify.lndo.site/index.php?view=scans (I'm using Lando to host it locally)

Warning: Undefined variable $records in /app/models/db.php on line 397 Fatal error: Uncaught Exception: 
Cannot insert scan with status "running" and records "" in /app/models/db.php:397 Stack trace: #0 
/app/actions/scan_all_pages.php(28): DataAccess::add_scan('running', 'a:2504:{i:0;a:1...') #1 {main} thrown 
in /app/models/db.php on line 397

This suggests that it can't connect to SQL?

But I was able to add a site, that generates a list of pages to scan.

Unsure how to fix. Thanks

In MVP 1.2 we limit users to 1,111 pages.

We do that so we can guarantee Equalify works on our supported system.

Perhaps we need to increase that limit?

Very few early testers needed over 1,111 pages.

If you want more pages, add a 👍 to this thread or comment with your use case.

I've tried scanning a new site www.cinuk.org

While the scan is running, the following line appears multiple times: >>> Unknown column 'tags' in 'field list'

It ends with this:

> Processing alerts...

|=========================================|
|               SCAN STOPPED              |
|=========================================|

Unknown column 'queued_alerts.tags' in 'field list'

And when I visit the Sites tab, the new site is showing as unscanned.

Using just a second-level and top-level domain (e.g. graceblake.com) throws an exception. PHP's FILTER_VALIDATE_URL filter doesn't consider it a URL.

This isn't a great user experience, but may not be a bug if you want to force the protocol to be specified.

When pointing to a WP site the per_page param is set to 100 you have to set $GLOBALS['page_limit'] to 100 or you get an error. Say for instance you wanted to limit the scan to 10 pages you get the following...

Begin scan on 21/09/2022 at 01:57:07.


> Processing sites...
- https://www.butler.edu
> Found 100 scannable pages.

|=========================================|
|               SCAN STOPPED              |
|=========================================|

You have too many pages.

Equalify allows up to 10 pages.

Archive sites or delete pages from WordPress/XML.

It seems like one should be an upper limit and the other the actual count. So it's more like, give me x number of pages but don't exceed y number.

Hi @bbertucc,

I accidentally based this off of the mvp-2 branch. If that's not the right thing to do, I can probably remove some of the extra code and reapply it to main.

If this qualifies for the bounty, please send it to Instant Messaging Freedom, the 501(c)(3) non-profit that helps support open communication tools.

Resolves #25

According to w3..

• Prepared statements reduce parsing time as the preparation on the query is done only once (although the statement is executed multiple times)
• Bound parameters minimize bandwidth to the server as you need send only the parameters each time, and not the whole query
• Prepared statements are very useful against SQL injections, because parameter values, which are transmitted later using a different protocol, need not be correctly escaped. If the original statement template is not derived from external input, SQL injection cannot occur.

Thanks @jrchamp!

Proper grammar and spelling make the Equalify code more readable. Unfortunately, I am plagued with dyslexia and many grammar/spelling errors slip into the main branch.

For Hacktoberfest, I invite anyone to read through main branch grammar and spelling. Create Pull Requests for any batch of errors you find.

With https://github.com/bbertucc/equalify/blob/main/index.php#L68, the only way to customize Equalify is to fork that file.

Just like Drupal installs start with a Drupal logo which is almost immediately replaced by an organization's logo, large organizations are going to want to customize this.

I was thinking that something along the lines of CiviCRM's footer might work well in the sidebar to link users back to the project instead of just the homepage of the instance.

When trying to add a new WordPress site for scanning, I am directed to an error page with the following message:

This page isn’t working service.equalify.app is currently unable to handle this request. HTTP ERROR 500

I am on MacOS Monterey using Chrome Version 107.0.5304.87 (Official Build) (arm64)

The Problem

Alerts are not filterable. For instance, if I want to only very alt related errors, I have to click on each page's alert block and sort related to the page. I can't just select an alt filter that would show me all of the alerts.

The Solution

A tagging system allows individual alerts to be sorted by pre-defined options. Each can be registered by a user or an integration with code like register_tags([['slug'=>$value, 'name'=>$value, 'description'=>$value, 'category'=>$value]]).

All tags related to an alert will be viewed in a new alert column:

Each tag links to a detail page with the tag's description and related, unignored, alerts:

Since we have lots of tags, tags will be navigatable as checkboxes in category-specific dropdowns:

Categorized dropdowns with tag checkboxes give new users a quick way to know tag options. They also make navigation more accessible than a dynamic multiselect, like Select2.

We should also only display categories with the most used tags. Other categories and tags are accessible under a "More Filters" button. That would focus the UX on the most used features.

Future Development

Tags allow us to create reports on the number of errors related to specific guidelines and compliance levels (#76). I also imagine this will lead to #96.

Work Plan

I'll develop a version of this. Happy to collaborate with anyone!

A user reported:

About half of the issues are for the same error "aria-hidden-focus" (least from a quick scan). Would be great if the tool said, "20 identical issues on 10 pages" or something like that.

This is going to become a bigger issue as we scan more sites and pages.

Problem

Load time of pages is too long because lots of DB requests via PHP happen every time the page loads. The DB requests are in essay since core data only changes when the scan runs or integrations/sites are activated/deactivated.

Solution

Generate JSON that page info is loaded from on scan completion and integration/site toggle. We can then load the JSON via PHP or rewrite the front end using a JavaScript framework like Vue.

Money arouses complex emotions, so I've avoided bringing it up in Equalify conversations. But there comes a time in every open source project's life when the "$" needs to come out, so let's talk money..

To start, I want to say that getting rich is not my goal for Equalify. I aim to make the web more accessible through better automated accessibility testing. This project is designed to inspire better tools that I and others build. That's not to say we're only building Equalify tools. WAVE and axe-core are great tools that I hope we push to be better. I will only actually code something when a solution doesn't exist (ie- crawling and testing thousands of pages, the main function of Equalify).

To establish a budget for 2023, maybe we can look at data in 2022..

Digital Ocean charges me $55-105/mo for managed hosting of a database and two servers. I'll probably need to pay them a bit more when the axe-core web service is up. I also paid WAVE $335 for users to use their API, but I think that cost will end when axe-core is integrated. Additionally, I would love to scale up the Equalify bug bounties. I gave away $699.55 in 2022, and think it's a fun way to push work forward.

As far as my time is concerned, I have no idea how to value my time. I can say that my personal 2023 budget is around $55k/yr for living expenses and savings. My best work comes when I devote myself full-time to a project, so I hope most of my cash comes from Equalify in 2023.

Considering all that, I guess I would like to raise >$56k in 2023? Does that sound right?

Now.. to the question of how to raise the money..

To fund the Equalify work (my own and others'), I'm either thinking about going a donation or paywalled route.

If we went a paywall route, equalify.app would cost $x/x alerts per month to use. We have 33 users using the service now. Based on current activity, I could see around 11 of the 33 users paying for Equalify.

What should we charge paying users?

I like multiples of 11, so perhaps we charge $11/mo to start. That's $121/mo for 11 users. I imagine those initial 11 users would scale up every month I did the work. We get about 6 new users a month, and I bet 2 of those users will pay. So that's $121 this month, $143 next month, .. yielding $2904 in 2023. Way shy of the $56k goal!

How about a donation route?

If went a donation route, I would go after sponsors to sustain the brunt of the cost then ask anyone who uses equalify.app for a suggested donation based on the number of alerts they have.

Pantheon generously gave me $20k in 2023. Various transactions led to a current balance of $4,727.40. I hope to put that money toward 2023's budget.

The folks at Pantheon suggested they would sponsor another year, but I really don't know if they will? Let's just say they do... $20k in the bank! Perhaps I'll go after a few more sponsors - I have some connection with Platform.sh, Github, GitLab, and Automattic. Could we get $40k in sponsorship???

If we got $40k in sponsorship, that would leave only $16k to reach my goal. That $16k could come in asking equalify.app users for donations. We need to suggest around $77/mo based on the math above to reach $16k.

Would people donate $77/mo to use Equalify? Sounds like too much to me. What should we do?

I want to go the donation route when comparing the paywall and donation route. Relying on donations means the folks who didn't have enough cash to pay for Equalify could get the service for free. That also builds a culture of open source, community-supported, creation.

What do you think?

EDIT: Adding the Beta 1 Milestone to this. Since Beta 1 represents a solution that we can grow our userbase on, I would love to have this question figured out by the time we reach Beta 1 (currently scheduled for 1/11/23).